0
点赞
收藏
分享

微信扫一扫

TCP/IP协议簇之传输层

王传学 2022-02-14 阅读 119
tcp/ip服务器网络

文章目录

传输层

负责数据能够从发送端传输接收端.

再谈端口号

端口号(Port)标识了一个主机上进行通信的不同的应用程序;

image-20211125110511794

在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过
netstat -n查看)

IP头中的协议号用来说明IP报文中承载的是哪种协议（一般是传输层协议，比如6 TCP，17 UDP；但也可能是网络层协议，比如1 ICMP；也可能是应用层协议，比如89 OSPF）

数据到达IP层后，会先检查IP首部中的协议号，再传给相应协议的模块。

下图中1和3的目标端口号和源端口号完全相同，但是他们各自的源IP地址不同。此外还有一种情况，那就是IP地址和端口全都一样，只有协议号不同。这种情况下，也会认为是两个不同的通信。

image-20211125110733033

端口号范围划分

认识知名端口号(Well-Know Port Number)

有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:

执行下面的命令, 可以看到知名端口号

cat /etc/services

我们自己写程序使用端口号时, 要避开这些知名端口号.

**注意：那些知名端口号与传输层协议并无关系，只要端口一致都将分配同一种程序进行处理。**例如，53端口在UDP和TCP中都用于DNS服务

两个问题

  1. 一个进程是否可以bind多个端口号?
    可以
  2. 一个端口号是否可以被多个进程bind?
    不能

netstat

netstat是一个用来查看网络状态的重要工具.
语法： netstat [选项]
**功能：**查看网络状态
常用选项：

pidof

在查看服务器的进程id时非常方便.
语法： pidof [进程名]
**功能：**通过进程名, 查看进程id

kill与pidof的配合使用

pidof name | xargs kill -9

xargs是将管道中的信息以参数形式传给kill，如果没有xargs，则是以IO形式给了kill，这样达不到kill效果。

UDP协议

长链接与短链接

一张网页实际上包含了多个资源，既然包含了多个资源，一次request就不能够将所有资源都申请到，而短链接(HTTP/1.0)只能支持一次request和response的交互，然后断开链接，要想继续申请网页资源就要再次建立链接、断开链接…直到将所有资源都申请完。而多次地建立链接和断开链接是有开销的(比如开辟空间创建数据结构)。长链接(HTTP/1.1)就解决了多次建立和断开链接的问题，建立一次长链接就可以实现多次request和response的交互。并且一次并不是只发送一个request，而是发送一批request，响应也是一批response。

UDP协议端格式

image-20211127102618194

Linux内核的UDP报头：

image-20211127103529476

UDP的特点

UDP传输的过程类似于寄信.

面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
用UDP传输100个字节的数据:

UDP的缓冲区

UDP的socket既能读, 也能写, 这个概念叫做 全双工

UDP使用注意事项

我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部).
然而64K在当今的互联网环境下, 是一个非常小的数字.
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

基于UDP的应用层协议

  • NFS: 网络文件系统
  • TFTP: 简单文件传输协议
  • DHCP: 动态主机配置协议
  • BOOTP: 启动协议(用于无盘设备启动)
  • DNS: 域名解析协议

当然, 也包括你自己写UDP程序时自定义的应用层协议;

TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

为什么有可靠性问题？

因为网络传输数据，线路更长

不可靠有哪些情况？

丢包，乱序，错误，接收缓冲区满了等等

TCP协议段格式

image-20211127105037115

TCP中没有表示包长度和数据长度的字段。可由IP层获知TCP的包长，由TCP的包长可知数据的长度。

  • TCP报头长度：20个字节(标准) + 选项

  • 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;

  • 4位TCP首部长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60，所以选项长度最大为40个字节

  • 32位序号/32位确认号: 32位序号：保证数据按序到达。32位确认号：反馈实际收到的数据。
    TCP对每个字节的数据都进行了编号，接收端通过编号来确认读取数据的顺序。比如现在client发送了三个字节的数据，给他们编号5，6，7，这些编号就在保留在32位序号中被发送到服务器端，服务器就按照5，6，7的顺序读取这三个字节的数据。而32位确认号就是为了给客户端反馈收到了哪些数据。如果5，6，7三个数据服务器都收到了，就会发送原序号+1的确认序号给客户端，表示确认序号之前的数据都收到了。如果收到了5，就发送6回去，表示6号之前的数据都收到了；收到了6，就发送7回去，表示7号之前的数据都收到了。而现在是收到了5，6，7三个信号，就要发送8回去，表示8之前的数据都收到了。
    再比如客户端发送了1-10000编号的数据，服务器反馈了5000，说明服务器接收到了5000之前的数据，客户端此时就要从5000开始发送。

    为什么需要两套序号呢？服务器端只关心32位编号，客户端只关心32位确认序号，这样一套编号不就可以了吗？

    因为TCP是全双工的，客户端和服务器可以同时进行通信，客户端返回确认序号也有可能同时发送了信息给客户端接收，所以需要两套序号。

  • 保留：6位标志位

    还有2个表示网络拥塞的标志位CWR、ECE，基本不使用。

    • URG(Urgent Flag): 紧急指针是否有效，也就是表示是否有紧急数据，紧急数据会被优先读取
    • ACK(Acknowledgement Flag): 确认是否收到数据
    • PSH(Push Flag): 提示接收端应用程序立刻从TCP缓冲区把数据读走，达到催促的效果
    • RST(Reset Flag): 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
      例如，在进行三次握手时，client接收到server的ACK后，就认为链接已经建立了，但它还要发送的ACK可能丢包了或者还没有到达server端，client此时就开始发送数据给server，server没有收到ACK，觉得莫名其妙，所以要求重新建立链接，在发送的TCP报头中设置RST。
    • SYN(Synchronize Flag): 请求建立连接; 我们把携带SYN标识的称为同步报文段
    • FIN(Fin Flag): 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段。主机收到FIN设置为1的TCP段后不必马上回复一个FIN包，而是可以等到缓冲区中的所有数据都已成功发送而被自动删除之后再发。

  • 16位窗口大小: TCP是有发送缓冲区和接收缓冲区的，窗口实际上就是反映自己当前接收缓冲区的剩余空间的大小，让对方知道自己目前的接收数据的能力，从而让对方控制发送数据的速度(流量控制)，否则接收缓冲区满了就会丢失数据，虽然有重发机制，但重发是有消耗的，所以控制发送速度更好一点。

  • 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也
    包含TCP数据部分.

  • 16位紧急指针: 当URG标志位为1时，紧急指针有效。假设有一组已经在套接字缓冲区中排队将要发送到对端的数据(1,2,3,4,5…N),在该缓冲区中要发送的数据末尾设置OOB标记作为缓冲区中最后一个字节,通常存在一个紧急指针指向OOB标记字节的下一个字节.而OOB标记字节的前一个字节就会作为紧急数据随同其之前一系列普通数据发送到对端。所以紧急指针是一个偏移量，且紧急数据只能有一个字节

  • 40字节头部选项: 暂时忽略

TCP协议不需要指明数据长度，因为它是面向字节流的，读多少取决于应用层；而UDP需要指明数据长度，因为UDP是面向数据报的，应用层要读数据就要读全部的数据，即有多少读多少。

之前我们使用的send不是直接发送到网络，而是拷贝至发送缓冲区， 因为网卡的处理速度太慢了，直接发送会被阻塞。recv也不是直接给应用层，而是拷贝到接收缓冲区。

http层的request和response一一对应，在TCP层不一定，这取决于接收端窗口的大小(接受数据的能力)，因为TCP是面向字节流的

Linux内核中的TCP报头

image-20211127113635763

确认应答(ACK)机制

可靠性：只要收到了对应的应答，就认为之前发送的数据对方已经收到。只有相对的可靠性，没有绝对的可靠性。

所以没有绝对的可靠性，因为永远有消息是没有ACK的。

确认应答机制：

image-20211127103808826

TCP将每个字节的数据都进行了编号. 即为序列号。接收者按照序列号的顺序读取数据

image-20211127103917448

每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发

通过序列号和确认应答号，TCP可以实现可靠传输

超时重传机制

image-20211127103736117

但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了

image-20211127104235706

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉.这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.
那么, 超时的时间如何确定?

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

连接管理机制

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

image-20211120112620748

服务端状态转化:

客户端状态转化:

如何理解链接？

链接本身是有成本的：空间+时间
TCP面向链接：三次握手成功，这意味着client和server需要维护链接

为什么一定要是三次握手？

首先，client和server双方要验证全双工，即双方能否正常通信，如果是一次或两次握手，容易受到洪水SYN攻击，也就是客户端可以不建立链接(只发送SYN，不建立连接，而服务器已经建立好了连接)，但可以给server发送SYN申请建立连接，如此向server发送大量的SYN，就造成了服务器的崩溃。
其次，为什么是三次而不是四次？观察上面的图，client在收到SYN+ACK后，就认为建立了连接，但实际上server还未收到ACK或ACK丢包了，这个短暂的时间间隙内，客户端认为连接已经建立了，这样客户端会为连接开辟空间消耗时间，而服务器要收到ACK才会正式建立连接，此时服务器只有一点小小的开销。如果是服务器发送最后一次ACK，因为有多个客户端连接服务器，服务器为了连接而产生的开销就十分大，甚至导致崩溃。所以要让client发送最后一次ACK。故握手的次数要是大于3的奇数次
最后，为什么不可以是5次，7次甚至更多次呢？因为3次握手的成本最小。3次握手就能解决，为什么还要握那么多次呢？

总结

三次握手的原因：

  1. 用最小成本验证全双工
  2. 让服务器不要出现链接建立的误判情况，减少服务器的资源浪费(奇数次握手)

下图是TCP状态转换的一个汇总

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NlFabd5U-1644383604031)(C:\Users\晏思俊\AppData\Roaming\Typora\typora-user-images\image-20211127104435380.png)]

关于 “半关闭” , 如果一方close, 另一方没有close, 则认为是半关闭状态。处于半关闭状态的时候, 可以接收数据, 但是不能发送数据. 相当于把文件描述符的写缓冲区操作关闭了.

注意: 半关闭一定是出现在主动关闭的一方.

理解TIME_WAIT状态

首先，TIME_WAIT状态是主动断开连接一方在收到FIN并发送ACK后进入的状态。为什么要等待呢？因为发送的ACK有可能丢包，而另一端没有收到ACK回应，就会再发一次FIN，此时主动断开链接的那一方还处于TIME_WAIT状态，收到FIN后，就知道之前发送的ACK丢包了，所以会再发一次。这就是TIME_WAIT的意义。如果它不等一段时间，ACK丢包后，对端再发一次FIN，此时它已经关闭链接了，于是永远都不会再发送ACK，对端就一直处于CLOSE_WAIT状态，没有释放资源。

现在做一个测试,首先启动server,然后启动client,然后用Ctrl-C使server终止,这时马上再运行server, 结果是

这是因为,虽然server的应用程序终止了,但TCP协议层的连接并没有完全断开,server还处于TIME_WAIT状态，因此不能再次监听同样的server端口.
我们用netstat命令查看一下:
image-20211127181207035

image-20211127180527637

想一想, 为什么是TIME_WAIT的时间是2MSL?

TIME_WAIT意义：

  1. 尽量保证最后一个ACK被对方收到，进而尽快释放服务器资源
  2. 等待历史数据在网络上进行消散(有可能有历史发送的数据还未到达，TIME_WAIT期间可以等待)

解决TIME_WAIT状态引起的bind失败的方法

在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

在bind前使用setsockopt()设置socket描述符的， 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符

_lsock是监听的套接字

image-20211127181840172

理解 CLOSE_WAIT 状态

以之前写过的 TCP 服务器为例, 我们稍加修改
将 close(sock); 这个代码去掉 我们编译运行服务器. 启动客户端链接, 查看 TCP 状态, 客户端服务器都为 ESTABLELISHED 状态, 没有问题.
然后我们关闭客户端程序, 观察 TCP 状态

tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN
5038/./dict_server
tcp 0 0 127.0.0.1:49958 127.0.0.1:9090 FIN_WAIT2 -
tcp 0 0 127.0.0.1:9090 127.0.0.1:49958 CLOSE_WAIT
5038/./dict_server

此时服务器进入了 CLOSE_WAIT 状态, 结合我们四次挥手的流程图, 可以认为四次挥手没有正确完成.

小结: 对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题

TCP以段为单位发送数据

在建立TCP连接的同时，也可以确定发送数据包的单位，我们也可以称其为“最大消息长度”(MSS:Maximum Segment Size)。最理想的情况是，最大消息长度正好是IP中不会被分片处理的最大数据长度。因为数据链路层有MAC帧最大长度的限制，所以IP层必须随其将数据包进行分片发送。

TCP在发送大量数据时，是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位。

MSS是在三次握手的时候，在两端主机之间计算得出。两端的主机在发出建立连接的请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应的MSS的大小。然后会在两者之间选择一个较小的值投入使用。

image-20220127105852807

①②通过建立连接的SYN包互相通知对方网络接口的MSS值

③在两者之间选一个较小的作为MSS的值，发送数据

滑动窗口

刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.
这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候

image-20211127182843575

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)

image-20211127181956523

image-20211127182710677

如何滑动？
收到的确认序号是多少，窗口就滑到哪个位置(窗口的左边对齐确认序号)
所以即使前面数据的ACK还未收到，也可以进行滑动。

image-20220127110441731

滑动窗口的理解：

滑动窗口的大小并不是固定的，因为对端的接收缓冲区可能满了，窗口大小就为0，此时滑动窗口大小也为0。

滑动窗口的大小 = min(对端窗口大小，拥塞窗口大小)

拥塞窗口是我们下面要介绍的。

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论.
情况一: 数据包已经抵达, ACK被丢了

image-20211127182727682

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;

情况二: 数据包直接丢了

image-20211127182746127

这种机制被称为 “高速重发控制”(也叫 “快重传” )

快重传与超时重传机制并不冲突，并且是互相补充的，如果当前一次只能发送两个TCP报文(快重传需要连续收到三次相同的确认应答才会触发)，就不会引发快重传，而此时数据丢了，就需要超时重传机制来帮我们重新发送数据。

流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,
就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

image-20211127182401593

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;
那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;

接收端的接收缓冲区满了，发送端知道后就停止发送数据，但发送端怎么知道它什么时候可以接收数据了呢？

接收端会发送窗口更新通知，发送端收到后才可继续发送。如果这个窗口更新通知在传送途中丢失，可能会导致无法继续通信。此时发送端就会时不时地发送一个叫做窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口大小信息。

拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能发生问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

image-20211127182807679

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初始时慢, 但是增长速度非常快.

image-20211127182320145

  • 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
  • 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

总结：

  1. 为什么会有拥塞控制？
    网路出了问题：大量丢包

  2. 如何实现拥塞控制？

    慢启动

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms

下图则是每隔两个数据段发送一次确认应答

image-20211127190542889

捎带应答

根据应用层协议，发送出去的消息到达对端，对端进行处理之后，会返回一个回执。即在很多情况下，客户端服务器在应用层也是“一发一收”的，意味着客户端给服务器说了“How are you”，服务器也会给客户端回一个“Fine，thank you”；

另外接受数据以后如果立刻返回数据，就无法实现捎带应答，所以是在延迟应答的基础上，进行的捎带应答。延迟确认应该是能够提高网络利用率从而降低计算机处理负荷的一种较优的处理机制。

那么这个时候ACK就可以搭顺风车了，和服务器回应的“Fine，thank you”一起回给客户端。

image-20211127190730614

面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

总结：TCP传送的数据不一定一次就全部发送给上一次或下一层，可以分批发送。

粘包问题

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

粘包问题实际上是由HTTP层解决的。

思考: 对于UDP协议来说, 是否也存在 “粘包问题” 呢?

不存在。

TCP异常情况

进程终止: 进程终止会释放文件描述符, 操作系统会在底层帮进程完成四次挥手,仍然可以发送FIN. 和正常关闭没有什么区别.

机器重启: 和进程终止的情况相同.

机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.

另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

TCP小结

为什么TCP这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能.
可靠性:

提高性能:

其他:

定时器扩展：定时器管理是由最小堆完成的，由堆顶元素判断是否有计时器到时间了，然后根据对应的编号拿到对应的处理方法，进行对应的处理。

基于TCP应用层协议

  • HTTP
  • HTTPS
  • SSH
  • Telnet
  • FTP
  • SMTP

当然, 也包括你自己写TCP程序时自定义的应用层协议;

TCP/UDP对比

我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较

归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.

用UDP实现可靠传输(经典面试题)

参考TCP的可靠性机制, 在应用层实现类似的逻辑;
例如:

TCP 相关实验

理解 listen 的第二个参数

基于之前封装的服务器和客户端实现以下测试代码
对于服务器, listen 的第二个参数设置为 2, 并且不调用 accept
test_server.cc

#include "tcp_socket.hpp"
int main(int argc, char* argv[]) {
    if (argc != 3) 
    {
        printf("Usage ./test_server [ip] [port]\n");
        return 1;
    }
    
    TcpSocket sock;
    bool ret = sock.Bind(argv[1], atoi(argv[2]));
    if (!ret) 
    {
        return 1;
    }
    
    ret = sock.Listen(2);
    if (!ret) 
    {
        return 1;
    }
    
    // 客户端不进行 accept
    while (1) 
    {
        sleep(1);
    }
    
	return 0;
}

test_client.cc

#include "tcp_socket.hpp"
int main(int argc, char* argv[]) {
    if (argc != 3) 
    {
        printf("Usage ./test_client [ip] [port]\n");
        return 1;
    }
    TcpSocket sock;
    bool ret = sock.Connect(argv[1], atoi(argv[2]));
    
    if (ret) 
    {
        printf("connect ok\n");
    } 
    else 
    {
        printf("connect failed\n");
    }
    while (1) 
    {
        sleep(1);
    }

    return 0;
}

此时启动 3 个客户端同时连接服务器, 用 netstat 查看服务器状态, 一切正常.

但是启动第四个客户端时, 发现服务器对于第四个连接的状态存在问题了

tcp 3 0 0.0.0.0:9090 0.0.0.0:* LISTEN
9084/./test_server
tcp 0 0 127.0.0.1:9090 127.0.0.1:48178 SYN_RECV -
    
tcp 0 0 127.0.0.1:9090 127.0.0.1:48176 ESTABLISHED -
    
tcp 0 0 127.0.0.1:48178 127.0.0.1:9090 ESTABLISHED
9140/./test_client
tcp 0 0 127.0.0.1:48174 127.0.0.1:9090 ESTABLISHED
9087/./test_client
tcp 0 0 127.0.0.1:48176 127.0.0.1:9090 ESTABLISHED
9088/./test_client
tcp 0 0 127.0.0.1:48172 127.0.0.1:9090 ESTABLISHED
9086/./test_client
tcp 0 0 127.0.0.1:9090 127.0.0.1:48174 ESTABLISHED -
    
tcp 0 0 127.0.0.1:9090 127.0.0.1:48172 ESTABLISHED -

客户端状态正常, 但是服务器端出现了 SYN_RECV 状态, 而不是 ESTABLISHED 状态
这是因为, Linux内核协议栈为一个tcp连接管理使用两个队列:

  1. 全链接队列（acceptd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）
  2. 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）
    通俗来说，就是当全链接队列满了时，再来进行链接的主机会进入SYN_SENT状态，服务器会进入SYN_RECV状态，半链接队列就是用来保存这些请求。

而全连接队列的长度会受到 listen 第二个参数的影响.
全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了.

这个队列的长度通过上述实验可知, 是 listen 的第二个参数 + 1.

为什么队列长度是listen的第二个参数+1？

查看部分内核代码来验证。

sock中有两个成员变量：sk_ack_backlog：当前已经在全链接队列中的链接个数。sk_max_ack_backlog：我们传递的第二个参数。判断全链接队列是否满的代码是：return sk->sk_ack_backlog > sk->sk_max_ack_backlog;，即当sk_ack_backlog == sk_max_ack_backlog + 1时，才返回true，即全链接队列已满。

如下图所示(图中手误将sk_max_ack_backlog写成了sk_max_backlog)：

image-20211129204632323

举报

相关推荐

TCP/IP协议簇

redis数据库java

TCP/IP协议栈_传输层_UDP和TCP

拥塞控制滑动窗口UDPTCPTCP/IP协议栈C/C++后端开发

传输层协议 ——— TCP协议

tcp网络协议linux网络

TCP/IP协议簇自学笔记

kubernetes容器云原生

传输层——TCP协议

tcp/ip网络协议网络

传输层 | UDP协议、TCP协议

学习前端javascript

传输层协议——TCP协议 （详解！！！）

tcp/ip网络协议网络

【网络编程】传输层协议——TCP协议

android

【Linux】【网络】传输层协议：TCP

网络linuxtcp/ip

【Linux】传输层协议：TCP/UDP

pythonflaskdjangophpvue.jsnode.js
0 条评论