负责数据可以从发送端传输接收端.

端口号(Port)在主机上识别不同的通信应用程序；

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

IP头部的协议号用来解释IP报文中承载的协议是什么(一般是传输层协议，比如6 TCP，17 UDP；但也可能是网络层协议，如1 ICMP；也可能是应用层协议，如89 OSPF）

数据到达IP层后，先检查IP第一部中的协议号，然后传输到相应协议的模块。

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

• 0 - 1023: 知名端口号， HTTP, FTP, SSH这些广泛使用的应用层协议， 他们的口号是固定的
• 1024 - 65535: 操作系统动态分配端口号. 端口号，客户端程序， 就是由操作系统从这个范围分配的

有些服务器很常用， 使用方便， 一些常用的服务器， 使用以下固定端口号：

• ssh服务器, 使用22端口
• ftp服务器, 使用21端口
• telnet服务器, 使用23端口
• http服务器, 使用80端口
• https服务器, 使用443

执行下列命令， 可见知名端口号

cat /etc/services

当我们用端口号写自己的程序时， 避免这些知名端口号.

**注：这些知名端口号与传输层协议无关，只要端口一致，就会分配相同的程序。**例如，53端口在UDP和TCP中都用于DNS服务

1. 一个过程是否可以bind多个端口号
   可以
2. 一个端口号能被多个过程接受吗？bind?
   不能

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

• n拒绝显示别名，所有可以显示的数字都转换成数字
• l 仅列出有在 Listen (监听) 的服务状态
• p 显示建立相关链接的程序名
• t (tcp)仅显示tcp相关选项
• u (udp)仅显示udp相关选项
• a (all)显示所有选项

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

kill与pidof的配合使用

pidof name | xargs kill -9

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

一个网页实际上包含多个资源，因为它包含多个资源，一次request所有资源都不能申请，短链接(HTTP/1.只能支持一次request和response交互，然后断开链接。如果你想继续申请网页资源，你必须再次建立链接并断开链接…直到申请完所有资源。多次建立链接和断开链接是有成本的(比如开放空间创建数据结构)。长链接(HTTP/1.1)解决了多次建立和断开链接的问题。建立长链接可以多次实现request和response的交互。而且一次不仅仅是一个request，而是发送一批request，响应也是一批response。

• UDP报头(第一部)占8字节。目的端口号是通过哈希找到相应的过程
• 源端口号是可选的，有时可能无法设置源端口号。当没有源端口号时，该字段的值设置为0。可用于无需返回的通信。
• 16位UDP长度, 表示整个数据报告(UDP首部 UDP最大长度的数据)；
  读完前八个字节后，再读一遍UDP减长8字节，就是UDP可以准确阅读数据报告的长度
• 如果验证和出错， 直接丢弃；

Linux内核的UDP报头：

UDP传输过程类似于寄信.

• 无连接: 知道对端的IP直接与端口号传输， 无需建立连接；
• 不可靠: 没有确认机制， 没有重传机制； 因网络故障不能发送给对方的， UDP协议层不会将任何错误信息返回到应用层；
• 面向数据报: 不能够灵活的控制读写数据的次数和数量;

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

若发送端调用一次sendto, 发送100个字节， 那么接收端也必须调用相应的一次recvfrom, 接收100个字节； 不能回收10次recvfrom, 每次接收10个节;

• UDP没有真正意义上的发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
• UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果
  缓冲区满了, 再到达的UDP数据就会被丢弃;

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

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

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

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

为什么有可靠性问题？

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

不可靠有哪些情况？

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

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报头

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

比如客户端对服务器发送了一些数据，服务器要向客户端发送确认收到的信息(ACK)，那客户端是不是还要再发一个ACK来告诉服务器他收到了应答呢？如果发了，服务器是不是又要发一次ACK来确认它收到了客户端的应答呢？这样就陷入了死循环(禁止套娃)。

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

确认应答机制：

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

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

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

• 主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;

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

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

• 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
• 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
• 如果超时时间设的太长, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁 发送重复的包;

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

• Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
• 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
• *如果仍然得不到应答, 等待 4 * 500ms 进行重传. 依次类推, 以指数形式递增.
• 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接.

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

服务端状态转化:

• [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
• [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端
  发送SYN确认报文.
• [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行
  读写数据了.
• [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器
  返回确认报文段并进入CLOSE_WAIT;
• [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当
  服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个
  ACK到来(这个ACK是客户端确认收到了FIN)
• [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接

客户端状态转化:

• [CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
• [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
• [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入
  FIN_WAIT_1;
• [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服
  务器的结束报文段;
• [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
• [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会
  进入CLOSED状态.

链接本身是有成本的：空间+时间
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)]

• 较粗的虚线表示服务端的状态变化情况;
• 较粗的实线表示客户端的状态变化情况;
• CLOSED是一个假想的起始点, 不是真实状态;

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

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

首先，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命令查看一下:

• TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
• 我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口;
• MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
• 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值;

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

• MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);
• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这
  时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

TIME_WAIT意义：

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

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

• 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).
• 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.
• 由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip,源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题.

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

_lsock是监听的套接字

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

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

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

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

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

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

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

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
• 发送前四个段的时候, 不需要等待任何ACK, 直接发送;
• 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 以此类推;
• 操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答，以便重发; 只有确认应答过的数据, 才能从缓冲区删掉;
• 窗口越大, 则网络的吞吐率就越高;

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

滑动窗口的理解：

把滑动窗口的两端想象成left和right两个指针， 右移就是left、right向后移动。
但内存是有限的，总会移动到内存的极限,所以不可能一直线性的向后滑动,可以把发送缓冲区理解成一个环形队列

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

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

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

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

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

情况二: 数据包直接丢了

• 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"
  一样;
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
• 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了，因为2001 - 7000的数据接收端其实之前就已
  经收到了, 被放到了接收端操作系统内核的接收缓冲区中;

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

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

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

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗
  口;

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

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
• 此处引入一个叫做慢启动的阈值
• TCP通信开始时，并没有设置相应的慢启动阈值。而是在超时重发时，才会设置为当时拥塞窗口一半的大小
• 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

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

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

总结：

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

2. 如何实现拥塞控制？

   慢启动

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

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
• 但实际上可能接收端处理的速度很快, 10ms之内就把500K数据从缓冲区消化掉了;
• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

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

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

• 数量限制: 每隔N个包就应答一次;
• 时间限制: 超过最大延迟时间就应答一次;

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

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

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

例子有：电子邮件协议的AMTP或POP、文件传输协议FTP中的连接控制部分等，例如远程登录中针对输入的字符进行回送校验也是对发送消息的一种回执。在此类通信中，TCP的确认应答和回执数据可以通过一个包发送，这种方式叫做捎带应答。通过这种机制，可以使收发的数据量较减少。

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

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

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

• 调用write时, 数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

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

• 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
• 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次
  read一个字节, 重复100次;

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

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
• 站在应用层的角度, 看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层
  数据包.

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

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲
  区从头开始按sizeof(Request)依次读取即可;
• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔
  符不和正文冲突即可);

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

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

不存在。

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.
• 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况.

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

服务器与客户端建立好链接，客户端崩了，这时客户端进程已经终止，不能自己完成挥手，但，套接字本质也是文件，进程退出后它打开的文件也会关闭，也就是关闭了它们进行通信的通道，所以两端就不能再进行通信了。四次挥手就由操作系统帮我们完成

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

服务器与客户端建立好链接，客户端关机了，情况和客户端崩了差不多，关机前操作系统要关闭所有进程，回收一定的资源，所以关闭了对应进行通信的文件，并且由操作系统完成四次挥手，

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

服务器与客户端建立好链接，网线拔了或电脑断电了，此时是硬件出了问题，操作系统也被关闭得措手不及，无法关闭文件，更无法帮我们完成挥手，但服务器有保活定时器帮我们检测对方的客户端是否还在，也有可能服务器正在给客户端发信息，但没有收到ACK，此时服务器也会发现客户端已经关闭了链接。

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

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

• 校验和
• 序列号(按序到达)
• 确认应答
• 超时重发
• 连接管理
• 流量控制
• 拥塞控制

提高性能:

• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答

其他:

定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)

保活定时器：长时间未访问的链接，如果保活计时器时间到了，就会把它关掉。比如客户端连上了服务器，一直连着但是不发请求，就可以通过保活计时器把它关掉。

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

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

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

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

• TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
• UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;

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

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

• 引入序列号, 保证数据顺序;
• 引入确认应答, 确保对端收到了数据;
• 引入超时重传, 如果隔一段时间没有应答, 就重发数据;
• …

基于之前封装的服务器和客户端实现以下测试代码
对于服务器, 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，即全链接队列已满。

如下图所示(图中手误