1、传输层概述

1.1 传输层协议

• 用户数据报协议 UDP (User Datagram Protocol) ：UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式。

• 传输控制协议TCP (Transmission Control Protocol) ：TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。

1.2 传输层的端口号

• 服务器端使用的端口号。这里又分为两类，最重要的一类叫做熟知端口号(well-known port number)或系统端口号，数值为 0～1023。这些数值可在网址www.iana.org查到。IANA 把这些端口号指派给了 TCP/IP 最重要的一些应用程序，让所有的用户都知道。常用的熟知端口号有：



另一类叫做登记端口号，数值为 1024～49151。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在 IANA 按照规定的手续登记，以防止重复。

• 客户端使用的端口号，数值为 49152～65535。由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号。这类端口号是留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在，这个端口号就可以供其他客户进程使用。

2、TCP和UDP协议介绍

2.1 TCP协议

• 面向连接：这就是说，应用程序在使用 TCP 协议之前，必须先建立 TCP 连接。而且每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的(一对一)，不能像 UDP 协议可以一个主机同时向多个主机发送消息。

• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证传送的数据无差错、不丢失、不重复、并且按序到达。

• 字节流：虽然应用程序和 TCP 交互是一次一个数据块，但 TCP 把应用程序交下来的数据仅仅是一连串的无结构的字节流。TCP 并不知道所传送的字节流的含义，但是可以保证接收方的应用程序有能力识别收到的字节流，把它还原成有意义的应用层数据。如下图所示

• 为了保证可靠性，采用超时重传和确认机制。TCP 为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)； 如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。

• 为了实现流量控制，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。

• 为了实现拥塞控制，采用慢启动算法。

2.2 TCP报文格式

• 源端口号 ：16 位，数据发起者的端口号。

• 目标端口号：16位，数据接收者的端口号。

• 序列号：32 位，序号范围是 [0, 2^32 - 1]，共 4294967296 个序号。TCP 是面向字节流的。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置，是由计算机生成的随机数作为其初始值。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是 301，而携带的数据共有 100 字节。这就表明：本报文段的数据的第一个字节的序号是 301，最后一个字节的序号是 400。显然，下一个报文段（如果还有的话）的数据序号应当从 401 开始，即下一个报文段的序号字段值应为 401。

• 确认应答号：32 位，是期望收到对方的下一个报文段数据的第一个字节的序号。例如，B正确收到了A发送过来的一个报文段，其序号字段值是501，而数据长度是200字节（序号501～700），这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。请注意，现在的确认号不是501，也不是700，而是701。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决不丢包的问题。

• 数据偏移/首部长度：4 位，指 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，这个字段实际上是指出TCP报文段的首部长度。单位是 32 位字(以 4 字节为计算单位)。

• 保留位：6 位，保留为今后使用，目前应置为 0。

• 控制位：6 个控制位说明本报文段的性质，分别对应六个字段。
• URG：该位为 1 时，告诉系统此报文段中有紧急数据，应尽快传送。
• ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。只有当 ACK=1 时确认应答号字段才有效；当 ACK=0 时，确认应答号无效。
• PSH：该值为 1 时，应尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
• RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
• SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
• FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

• 窗口大小：16 位，窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口），窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。例如，设确认号是 701，窗口字段是 1000。这就表明，从 701 号算起，发送此报文段的一方还有接收 1000 个字节数据（字节序号是 701 ～ 1700）的接收缓存空间。窗口字段明确指出了现在允许对方发送的数据量，用于流量控制。

• 检验和：16 位，用于检测发送过程中是否出现错误，检验和字段检验的范围包括首部和数据这两部分。

• 紧急指针：16 位，紧急指针仅在 URG = 1 时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。

• 选项：长度可变，最长可达40字节。TCP 最初只规定了一种选项，即最大报文段长度 MSS( MSS并不是整个TCP报文段的最大长度，而是“TCP报文段长度减去TCP首部长度”)。后面又陆续增加了几个选项。如窗口扩大选项、时间戳选项等[RFC 1323]。以后又增加了有关选择确认(SACK)选项[RFC 2018]。

• 填充：这是为了使整个首部长度是 4 字节的整数倍。

• 源地址

• 源端口

• 目的地址

• 目的端口

• MTU：Maximum Transmit Unit，最大传输单元，即物理接口（数据链路层）提供给其上层（通常是IP层）最大一次传输数据的大小。默认值是 1500 字节。如果 IP 层有小于等于 MTU 大小的数据需要发送，只需要一个 IP 包就可以完成发送任务；当 IP 层有一个超过 MTU 大小的数据要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU，这样才能完成数据的发送。

• MSS：Maximum Segment Size ，最大报文段长度，即 TCP 提交给 IP 层最大报文大小，这个报文大小是除去 IP 和 TCP 头部之后的数据的最大⻓度。

一般来说，MTU = MSS + IP 头部长度 + TCP 头部长度

2.3 UDP协议

• UDP 是无连接的，即发送数据之前不需要建立连接（当然，发送数据结束时也没有连接可释放），因此减少了开销和发送数据之前的时延。

• UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数）。

• UDP 是面向报文的。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。

• UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用（如 IP 电话、实时视频会议等）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP 正好适合这种要求。

• UDP支持一对一、一对多、多对一和多对多的交互通信。

• UDP的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

2.4 UDP报文格式

• 源端口号：在需要对方回信时选用。不需要时可用全0。

• 目的端口号：这在终点交付报文时必须要使用到。

• 包⻓度：该字段保存了 UDP 首部的⻓度跟数据的⻓度之和，其最小值是8（仅有首部）。

• 校验和：检测 UDP 用户数据报在传输中是否有错。有错就丢弃。

2.5 TCP和UDP的区别

1. 连接
• TCP 是面向连接的传输层协议，传输数据前先要建立连接。
• UDP 是不需要连接，即刻传输数据。

2. 服务对象
• TCP 是一对一的两点服务，即一条连接只有两个端点。
• UDP 支持一对一、一对多、多对多的交互通信

3. 可靠性
• TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
• UDP 是尽最大努力交付，不保证可靠交付数据。

4. 拥塞控制、流量控制
• TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
• UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

5. 首部开销
• TCP 首部⻓度较⻓，会有一定的开销，首部在没有使用「选项」字段时是20个字节，如果使用了「选项」字段则会变⻓的。
• UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

6. 传输方式
• TCP 是流式传输，没有边界，但保证顺序和可靠。
• UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

7. 分片不同
• TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
• UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层，但是如果中途丢了一个分片，在实现可靠传输的 UDP 时则就需要重传所有的数据包，这样 传输效率非常差，所以通常 UDP 的报文应该小于 MTU。

2.6 使用Wireshark解析TCP报文

• Source Port：源端口号为 42944 。

• Destination Post：目标端口号为 9200 。

• Sequence Number：序列号，真实值是 2737882246，这是计算机随机生成的一串数字。相对偏移值是 0，这里是相对本次 TCP 连接的其他报文的偏移量。

• Acknowledgement Number：确认应答号，真实值和相对偏移值都是 0。

• Header Length：首部长度，即 TCP 报文除去报文数据之外的报文首部长度。这里是 8，即 8 * 4 = 32 字节。

• Flags：这里六位保留位都是 0，控制位里面只有 SYN = 1。TCP 规定除了最初建立连接时的 SYN 位必须设置为 1 。

• Window：服务器向客户端返回的滑动窗口大小为 43690。

• Checksum：校验和。

• Urgent Pointer：紧急指针。

• Options：可选项。这里标明了 MSS 为 65495 字节。

3、三次握手

3.1 三次握手过程

• 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。

• 客户端会随机初始化序号( client_isn )，将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志 位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

• 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号( server_isn )，将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1 , 接着把 SYN 和 ACK 标志位置为 1 。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

• 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位 置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客 户到服务器的数据，之后客户端处于 ESTABLISHED 状态。

• 服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。

注意：第三次握手是可以携带数据的，前两次握手是不可以携带数据的。

• 如果是历史连接(序列号过期或超时)，则第三次握手发送的报文是 RST 报文，以此中止历史连接。

• 如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接。

为什么不是两次？

为什么不是四次？

3.2 半连接队列和全连接队列

• 半连接队列，也称 SYN 队列

• 全连接队列，也称 accepet 队列

3.3 SYN攻击

• 当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」。

• 计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端。

• 服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。

• 最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。

3.4 TCP的保活机制

• tcp_keepalive_time=7200：表示保活时间是 7200 秒(2小时)，也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制

• tcp_keepalive_intvl=75：表示每次检测间隔 75 秒;

• tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

4、四次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。服务器进程这时应通知高层应用进程，因而A → B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭(half-close)状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。

• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态，等待服务端发出的连接释放报文段。

• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态，等待客户端的确认。

• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态。

• 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。

• 客户端在经过 2MSL 时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

• 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

• 防止本次连接旧的已经失效的报文出现在下次连接。如果 TIME-WAIT 过短或者没有，假如网络拥堵，关闭本次连接再重新打开连接之后，旧连接的数据包才到达，就会造成数据混乱。而足够长的 TIME-WAIT 足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

• 保证客户端发送的四次挥手的最后一个报文能够到达服务端。四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSED 状态了，那么服务端则会一直处在 LASE_ACK 状态，后面客户端和服务端就不能正常建立连接。而足够长的 TIME-WAIT 可以保证服务端没有收到四次挥手的最后一个 ACK 报文时，则会重发 FIN 关闭连接报文并等待新的 ACK 报文，从而帮助双方都正确关闭。

• 复用处于 TIME_WAIT 的 socket 为新的连接所用。客户端在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用。使用 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 参数。

5、重传机制

• 超时重传

• 快速重传

• 选择重传

5.1 超时重传

• RTT (Round-Trip Time)：往返时间，也就是从数据发出去到收到相应确认所需的时间。

• RTO (Retransmission Timeout)：超时重传时间。

• 当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差;

• 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

5.2 快速重传

5.3 选择重传

5.3.1 SACK机制

5.3.2 D-SACK机制

• 让发送方知道，是发送的包丢了，还是返回的 ACK 包丢了；

• 网络上是否出现了包失序；

• 数据包是否被网络上的路由器复制并转发了

• 是不是自己的 timeout 太小了，导致重传

1. 第一个段将包含重复收到的报文段的序号

2. 跟在 D-SACK 之后的 SACK 将按照 SACK 的方式工作

3. 如果有多个被重复接收的报文段，则 D-SACK 只包含其中第一个

1. 如果 SACK 的第一个段的范围被 ACK 所覆盖，那么就是 D-SACK

2. 如果 SACK 的第一个段的范围被 SACK 的第二个段覆盖，那么就是 D-SACK

6、流量控制

6.1 滑动窗口

6.1.1 发送方的滑动窗口

• SND.WND：表示发送窗口的大小，大小是由接收方指定的。

• SND.UNA：指向已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。是绝对指针。

• SND.NXT：指向未发送但可发送的第一个字节的序列号，也就是 #3 的第一个 字节。绝对指针。

• 指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移就可以指向 #4 的第一个字节了。

• 发送窗口：又称为通知窗口，发送窗口 = SND.WND

• 可用窗口：又称为有效窗口，可用窗口大小 = SND.WND - (SND.NXT - SND.UNA)

6.1.2 接收方的滑动窗口

• RCV.WND：表示接收窗口的大小，它会通告给发送方。

• RCV.NXT：是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字 节。

• 指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移􏰀，就可以指向 #4 的第一个字节了。

1. 发送应用程序传送给发送方 TCP 准备发送的数据；

2. TCP 已发送出但尚未收到确认的数据。

1. 按序到达的、但尚未被接收应用程序读取的数据；

2. 未按序到达的数据。

6.2 利用滑动窗口实现流量控制

6.3 零窗口和窗口探测

• 发送方一直等待非 0 窗口通知。

• 接收方一直等待发送方发送数据。

• 如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器。

• 如果接收窗口不是 0，那么死锁的局面就可以被打破了。

6.4 延迟确认和Nagle算法

• 对于发送方来说可以使用 Nagle算法

• 对于接收方来说可以使用 延迟确认。

6.4.1 Nagle算法

• 一开始由于没有已发送未确认的报文，所以就立刻发了 H 字符。

• 接着，在还没收到对 H 字符的确认报文时，发送方就一直在囤积数据，直到收到了确认报文后，此时没有已发送未确认的报文，于是就把囤积后的 ELL 字符一起发给了接收方。

• 等收到对 ELL 字符的确认报文后，于是把最后一个 O 字符发送了出去。

6.4.2 延迟确认

• 当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方。

• 当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送

• 如果在延迟等待发送 ACK 期间，对方的第二个数据报文又到达了，这时就会立刻发送 ACK

• 发送方先发出一个小报文，接收方收到后，由于延迟确认机制，自己又没有要发送的数据，只能干等着发送方的下一个报文到达;

• 而发送方由于 Nagle 算法机制，在未收到第一个报文的确认前，是不会发送后续的数据。所以接收方只能等待最大时间 200 ms 后，才回 ACK 报文，发送方收到第一个报文的确认报文后，也才可以发送后续的数据。

7、拥塞控制

• 慢启动（Slow Start）

• 拥塞避免（Congestion Avoidance）

• 快速重传（Fast Retransmit）

• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

• 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

• 设某个光纤网络的链路传输速率为 1000Gb/s。有一个巨型计算机向一个 PC 机以 1Gb/s 的速率传送文件。显然，网络本身的带宽是足够大的，因而不存在产生拥塞的问题。但流量控制却是必需的，因为巨型计算机必须经常停下来，以便使 PC 机来得及接收。

• 但如果有另一个网络，其链路传输速率为 1Mb/s，而有 1000 台大型计算机连接在这个网络上。假定其中的 500 台计算机分别向其余的 500 台计算机以 100kb/s 的速率发送文件。那么现在的问题已不是接收端的大型计算机是否来得及接收，而是整个网络的输入负载是否超过网络所能承受的。

7.1 慢启动

拥塞窗口 cwnd 、发送窗口 swnd 和接收窗口 rwnd 的关系：swnd = min(cwnd, rwnd)，也就是说发送窗口是拥塞窗口和接收窗口中的最小值。但是 rwnd 是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑 rwnd 的值。

• 当 cwnd < ssthresh 时，使用「慢启动算法」。

• 当 cwnd > ssthresh 时，就会使用「拥塞避免算法」。

• 当 cwnd = ssthresh 时，既可使用「慢启动算法」，也可使用「拥塞避免算法」。

• 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个

• 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个

• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

7.2 拥塞避免

• 因为 ssthresh 为 8，当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9个 MSS 大小的数据，变成了线性增⻓。

1. ssthresh = cwnd/2。

2. cwnd 重置为 1。

3. 进入慢启动算法。

7.3 快速重传和快速恢复

1. ssthresh = cwnd/2

2. cwnd = ssthresh + 3(这里的 ssthresh 是第一步的计算结果，3 是指快速重传收到的三个重复的 ACK），进入快速恢复算法。

3. 如果收到重复数据的 ACK，那么 cwnd 增加 1。

4. 如果收到新数据的 ACK 后，把 cwnd 设置为 ssthresh 最开始的值，然后再次进入拥塞避免状态。原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的拥塞避免状态了。

7.5 拥塞避免算法过程

1. 当新建连接时，cwnd 初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd 就增加1个MSS大小。这样 cwnd 的值就随着网络往返时间(RTT)呈指数级增长。

2. 当 cwnd 超过慢启动门限 ssthresh 后，慢启动过程结束，进入拥塞避免算法。当窗口中所有的报文段都被确认时，cwnd 的大小加 1。 cwnd 的值就随着 RTT 开始线性增加。

3. 当检测到拥塞状态（判断拥塞的依据是 TCP 对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到 ACK 报文，或者连续三次收到相同的 ACK 报文，就判断出现了拥塞情况。），进入快读重传阶段，立刻连续发送三次丢失的报文段的前一个报文段的 ACK，然后进入快速恢复算法。

4. 把ssthresh 的值减半，然后 cwnd 设置为 ssthresh 新值的一半加 3，再收到重复的 ACK 时，cwnd 增加 1。当收到新的数据包的 ACK 时，把 cwnd 设置为 ssthresh 的原始值。原因是既然收到了新数据的 ACK ，说明重复 ACK 时的数据都已收到，快速恢复过程已经结束，可以回到恢复之前的状态了，再次进入拥塞避免算法。

常见问题

TCP为什么是可靠的协议

• 三次握手和四次挥手保证连接是可靠的。

• 基于序列号的确认应答机制，保证数据包的有序性。

• 对于没有收到数据包，提供重传机制。

• 为了协调发送方的发送包和接收方的接收包的速度，提供流量控制机制。

• 为了维护网络环境的稳定，提供拥塞控制机制。

解决time_wait过多的问题

解决CLOSE_WAIT过多的问题

泛洪攻击