传输层——UDP+TCP

传输层

 从通信和信息处理的角度，传输层向它上面的应用层提供通信服务，它属于面向通信的最高层，同时也是用户功能的最底层。网络层为主机之间的通信提供服务，而运输层则是在网络层的基础之上，为应用进程之间的通信提供服务。

其中TCP/IP运输层的两个重要协议：
1️⃣用户数据报协议UDP(User Datagram Protocol)
2️⃣传输控制协议TCP(Transmission Control Protocol)

UDP协议

UDP 概述

UDP的主要特点是：
1️⃣无连接
2️⃣不可靠
3️⃣面向报文的
4️⃣没有拥塞控制
5️⃣支持一对一，一对多，多对一和多对多的交互通信
6️⃣首部开销小

UDP协议的报文

• 16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度。
• 如果校验和出错，就会直接丢弃。

UDP是如何做到封装和解包的？

封装：就是给数据添加上定长报头。
解包：就是将报头和有效载荷分离。

UDP是如何做到向上交付的？(分用问题)

a.报头和有效载荷的分离。
b.根据目的端口号，交付有效载荷给上层应用。

报头中有一个字段：16位目的端口号，当一个报文被目标主机收到之后，通过这个端口号，就可以准确的交付给对应的应用进程。此处有恰好解释了，我们在写套接字代码的时候，绑定端口号时为啥要用uint16_t类型的变量，因为这是协议的规定。

Linux是C语言写的，请问是如何看待UDP报文的？

如下所示，用结构体来描述UDP报文：

struct udp_hdr
{
	uint32_t src_port:16;
	uint32_t dst_port:16;
	uint32_t total:16;
	uint32_t check:16;
};

UDP主要特点

• 无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接。
• 不可靠：没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息。
• 面向数据报：不能够灵活的控制读写数据的次数和数量。

面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并，而是保留这些报文的边界，UDP一次交付一个完整的报文。

• 用UDP传输100个字节的数据：
  如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

UDP的缓冲区
read/recvfrom write/sendto 这几个函数，与其说是收发函数，不如说是拷贝函数。本质上我们发送数据，表面上是发送到网络中去，实质上是将数据拷贝到下层的TCP和UDP缓冲区中去，拷贝完成之后，具体该数据什么时候发，发多少，完全由操作系统(传输层)来决定，这个步骤由OS自动完成。所以传输层给我们提供了更多传输数据的策略！

缓冲区存在的价值：一方面要让传输层能够定制一些发送数据的策略，另一方面它将应用层协议与下层的通信细节进行了解耦。

• UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作。
• UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓冲区满了，再到达的UDP数据就会被丢弃。
• UDP的socket既能读，也能写，这个概念叫做全双工(意思就是sendto和recvfrom可以同时被调用)。

UDP使用注意事项

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

基于UDP的应用层协议

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

TCP协议

TCP 概述

主要特点：
1️⃣面向连接
2️⃣每一条连接只能有两个端点，只能是点对点的
3️⃣可靠的
4️⃣全双工
5️⃣面向字节流

平时做事情有两步：
1、做决策
2、做执行

TCP报文格式

各个字段解释

• 源/目的端口号：表数据从哪个进程来，发送到哪个进程去。
• 32位序号和32位确认序号：后面细讲，这个字段很重要。
• 4位TCP首部长度：表示该TCP头部有多少个32位bit(有多少4字节)，所以TCP头部最大长度是15*4=60。注意：首部是有单位的——4字节，因为TCP协议规定了首部长度为定长20字节，所以4位首部长度一般为5，二进制就是0101。
• 6位标置位：后面细讲，很重要。
• 16位窗口大小：后面在说。
• 16位校验和：发送端填充，CRC校验。接收端不能通过，则认为数据有问题，此处的校验和不光包含TCP首部，也包含TCP数据部分。
• 16位紧急指针：标识哪部分数据时紧急数据。
• 40字节头部选项：暂时忽略。

TCP是如何封装和解包的？

有个字段叫做4位首部长度，能够将报头和有效载荷分离。
它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。

TCP是如何向上交付的？

有个字段叫做16位端口号，通过它将数据交付给上层应用。

确认应答机制(最重要的机制)

TCP叫做保证可靠性，必须要理解TCP中可靠性最核心的机制：基于序号的确认应答机制！

①确认应答机制，通过应答，来确认上一条我发的信息被对方100%收到了。总会遇到一条最新的消息没有应答！我们就无法保证整个通信是可靠的。所以TCP并不是100%可靠的，只要一条消息被应答，我们就能确认该消息被对方100%收到了。
衍生出：消息在传输过程中，世界上并不存在100%可靠的协议。

②TCP常规可靠性——确认应答的工作方式。
无论是客户端给服务器发消息，还是服务器给客户端发消息，只要我们针对一个方向上，发送的每一个消息都有对应的确认，我们就能保证发送的数据被对方可靠的收到了。我们双方都给出确认，我们就能够保证历史数据被对方可靠收到了，这就叫做100%保证可靠性。

③发送的数据都是报文。可以并行发送数据。
发送报文的顺序是1 2 3 4 5
接受方接受的顺序不一定是1 2 3 4 5(可能是乱序)。
可靠性除了保证被对方收到，也要保证按序到达。一旦乱序，可能会造成业务逻辑紊乱。所以TCP报头里面有个字段——32位序号，按照序号的排序顺序，来排序接收的报文，这样来保证接受方收到的报文是有序的。

④如何确认？
TCP报头中有一个字段——确认序号，是对历史报文确认序号 +1。

当发送放发送的消息，收到确认应答TCP后，可以通过确认序号，来辨别是对哪一个报文的确认。

TCP将每个字节的数据都进行了编号，即为序列号(32位确认序号)，每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。

注意：无论是数据还是应答，本质都是一个报文，图中的每一根线，都代表一个报文。 发送和接收的都是完整的TCP报文，即使里面没有携带数据，也要有完整的TCP报头首部，即那些字段也要填充完毕。

⑤一个报文里面，既有序号，也有确认序号，为什么要有两个独立的字段呢？
我们上述的讨论过程，只是数据单方向的发送，记住TCP是全双工的协议(我在发消息的时候，你可能在给我确认，我发送确认的时候，你可能在给我发送消息)。
双方通信的时候，一个报文，既可以携带要发送的数据，也可能携带对历史报文的确认！所以仅仅只用一个字段是不行的。

TCP协议的缓冲区问题

TCP协议是自带发送和接收缓冲区的！(TCP内部malloc申请2段内存空间)
write、send与其说是发送函数，不如理解成为拷贝接口，应用层进行send并不是把数据发送到网络中去，而是把数据拷贝到TCP的发送缓冲区当中，接收端也是如此。

为什么要有缓冲区呢？
1、提高应用层的效率。
2、只有操作系统、TCP协议可以知道网路，乃至对方的状态明细，所以也有只有TCP协议，能处理如何发？什么时候发？发多少？出错了怎么办？等细节问题。(传输 控制 协议)
缓冲区存在的意义：因为缓冲区的存在，可以做到应用层和TCP进行解耦！

16位窗口大小

我们给对方发送大量的数据的时候，对方可能来不及接收。

所以我们需要一个流量控制的机制
可以在应答报文中，在报头里面填上我自己的接收缓冲区剩余空间的大小，这个空间大小就对应TCP报文字段中的16位窗口大小。

根据这个窗口大小，发送方就能知道对方的接收能力，从而动态的调整发送数据的数量和速率。
例如：发送一个报文，其确认号是701，窗口大小为1000，这就是告诉对方，从701号开始，我(即发送此报文段的一方)的接收缓冲区还可以接收1000字节的数据，字节序号是701~1700，你在给我发送数据时，必须考虑到我的接收缓冲区容量。
总之窗口大小明确指出了现在允许对方发送的数据量。窗口值经常在动态变化着。

6个标记位

TCP是面向连接的，TCP创建套接字的通信过程中，要先connect！本质上的面向连接就是，先建立连接。

如何建立连接？
三次握手——三次数据交换，即交换三次报文。

server可能在任何一个时刻，都有可能有成百上千个报文在向server发送数据。
server首先面临的是，面对大量的TCP报文，如何区分各个报文的类别？(或者说为什么需要6个标志位这个字段？)
通过TCP的标志位来区分，这6个标志位其实表征的是不同种类的TCP报文。

①ACK

ACK表示对报文作确认，确认序号表示对哪一个报文之前的报文作确认。
仅当ACK=1时确认序号字段才有效，当ACK=0时，确认序号无效，TCP规定，在连接建立以后所有传送的报文段都必须把ACK置为1。

②SYN

server端可能会收到连接建立的请求，server端如何区分client端发来的报文是请求呢？
所以就有了SYN同步标记位。在连接建立时用来同步32位序号。当SYN=1时而ACK=0时，表明这是一个连接请求报文段。对方若是同意建立连接，则会在响应报文段中是使SYN=1和ACK=1。因此，SYN置为1就表示这是一个连接请求或者连接接收报文。

③RST

当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后在重新建立运输连接。将RST置为1还用来拒绝一个非法的报文段或者拒绝打开一个连接。因此，RST也可以称为重建位或者重置位。
不要以为3次握手就必须成功，它是有失败的可能的，其中第三次握手是没有响应的(前两次握手，并不害怕丢失了，因为我们会有ACK作确认)，我们无法确认该报文被对方收到了。所以三次握手是以较大概率建立连接的过程，一般而言，双方握手成功是有一个短暂的时间差的。

不是要三次握手吗？那么是不是意味着，client端要3次，server端也要三次。
所以client在第三次，只要它把报文发出去了，它就认为连接建立完成了。server端只要收到第三次server端发送的报文，它就认为连接建立成功了。

我们最为担心的还是第三次ACK丢失了！！！
此时client认为连接已经建立好了，而server的连接还没有完成。此时client极大可能开始发送数据了，但是server端认为连接都没有建立好，你就给我发送数据了，所以server端会发送一个携带RST的报文返回给client端，此时client立马意识到，自己第三次握手失败了，连接建立失败了，client立马就关掉了它建立的连接。
上述例子，只是连接异常的一种情况，只要双方连接出现异常，都可以使用rest标记位来进行连接重置。

④PSH

当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即，立即就能收到对方的响应，在这种情况下，TCP就可以使用推送PSH操作，这时发送TCP把PSH置为1，并且立即创建一个报文发送出去，接收方收到报文中PSH=1后，就尽快地交付给接收进程，而不是再等待整个缓冲区填满过后再向上交付。

⑤URG

和16位紧急指针搭配使用。
目前，因为TCP有按序到达！每一个报文，什么时候被上层读取到基本是确定的！
如果想让一个数据尽快的被上层读到，可以设置URG：表明该报文中携带了紧急数据，需要被优先处理！

那么紧急数据在哪里?
由16位紧急指针指向。TCP的紧急指针只能传输一个字节，意思就是只能读取一个字节。
send函数的最后一个参数是flags，其中可以设置字段，有一个字段叫做MSG_OOB

out-of-band 带外数据

⑥FIN

用来释放一个连接。当FIN=1时，表明此报文的发送方数据已发送完毕，并且要求释放运输连接。
一般而言:
建立链接的一般是client，断开连接是双方的事情，双方随时都有可能。

三次握手

1、过程

2、建立连接，我们这里要理解一下什么是连接？
server存在大量的连接，那么server要不要管理这些连接呢？
必须的，先描述再组织！
所以建立连接的本质：三次握手成功，一定要在双方的操作系统内，为维护该连接创建对应的数据结构，而且双方维护连接是有成本的(时间+空间)！

为什么是3次握手呢？而不是1，2，3，4，5，6次？
1️⃣确认双方主机是否健康。
2️⃣验证全双工，三次握手，是双方看到数据都有收发的最小次数。

四次挥手

为什么是4次挥手？
断开链接本质：双方达成连接都应该断开的共识，就是一个通知对方的机制，四次挥手是协商断开链接的最小次数。

超时重传机制

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

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

• 因此主机B会收到很多重复数据，那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。
• 这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。(去重也是可靠性的体现)

那么, 如果超时的时间如何确定?

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

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

• Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
• 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。
• 如果仍然得不到应答，等待 4*500ms 进行重传. 依次类推, 以指数形式递增。
• 累计到一定的重传次数，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状态。

TIME_WAIT状态

在四次挥手过程中，主动断开连接的一方，会进入TIME_WAIT状态，其中对于主动断开连接的一方它认为自己的四次挥手已经完成了，但是TCP不会让你马上释放连接资源，因为无法保证最后一个ACK被对方收到了。

为什么是2MSL？
1️⃣尽量保证历史发送的网络数据在网络中消散
2️⃣尽量的保证，最后一个ACK被对方收到

Bind error的原因？
主动断开连接的一方进入TIME_WAIT状态，连接并没有被释放，端口依旧还被占用，虽然已经没有人在用此端口了。如果此时再去绑定同样的端口，就会出现bind error，这不就是同一个端口被多个进程所绑定吗，这是不行的。

怎么解决Bind error的问题？

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

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

static int Socket()
{
   int sock = socket(AF_INET, SOCK_STREAM, 0);
   if (sock < 0)
   {
      cerr << "create socket failed!" << endl;
       exit(2);
   }
   int opt=1;                                                                     
   setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
   return sock;
}

这样就不会出现bind error的问题了：

无法立即重启bind，会有什么危害？
对于大型互联网公司会造成重大经济损失，例如淘宝的双11活动，一秒钟的损失都是上百万。我们做测试的时候，此端口号bind error，我们可以换一个端口号，但是实际应用中，端口和IP是不能随意更换的。所以我们要设置SO_REUSEADDR。

CLOSE_WAIT状态

将服务器部分代码屏蔽不做任何处理，包括不关闭fd

我们重新编译，启动客户端，查看TCP状态，其中客户端都是ESTABLISHED状态，没有问题。然后我们关闭客户端程序，再查看TCP状态：

此时服务器进入CLOSE_WAIT状态，结合四次挥手的流程图，可以认为四次挥手没有正确的完成。对于服务器上出现大量的CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭socket, 导致四次挥手没有正确完成。这是一个 BUG，只需要加上对应的close即可解决问题。
启示：
1️⃣一个fd用完，一定要关闭fd。
2️⃣fd是有限的，如果不及时关闭会造成fd泄露。

滑动窗口

报文中的窗口大小字段，表明的是自己的接收缓冲区的接收能力。
刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候。

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

一次发送多少数据呢？
并不是由发送方决定，而是由接受方决定。

滑动窗口的概念：

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

其中缓冲区可以划分为三部分
①已经发送
②可以/已经发送，但是还没有收到ACK(可以暂时不需要ACK)
③没有发送

滑动窗口的大小是可以改变的，并非固定大小的，例如由于接收方的应用层来不及将接收缓冲区数据拿走，那么此时滑动窗口只会把左侧给移动过去，右侧是不会移动的。

所以：滑动窗口的滑动是和对方的窗口大小(接收能力)强相关的！滑动窗口是不可能向左滑动的！

模拟滑动窗口：

如果出现了丢包，如何进行重传？这里分两种情况：
第一种情况：数据包已经抵达，中间部分ACK丢了

第二种情况：数据包直接丢了

虽然服务端已经收到了2000,3000,4000等这样的报文，但是因为确认序号规定了：某个序号之前的所有报文已经被收到了。但是服务端唯独没有收到1000~2000的报文，所以ACK的时候，服务端只能发送1001，但是同时客户端按理应该收到不同的确认应答，但是收到3个同样的确认应答，所以此时客户端就意识到1000 ~2000的报文丢失了，它就马上进行重传。这种机制被称作“快重传”。

快重传与超时重传
超时重传是基础，在它之上才出现了快重传，快字说明了超时重传就显得慢。

流量控制

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

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端。
• 窗口大小字段越大, 说明网络的吞吐量越高。
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端。
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度。
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。

什么时候才会有流量控制？
第一次发送方并不知道接收方的接收能力，所以并不知道窗口大小。什么时候取决于对方什么时候给我发送的第一个报文，这第一个报文不一定是数据报文，而是三次握手阶段，我们就已经交互了，所以是在前两次握手期间，双方协商窗口大小，根据对方的报文中的窗口大小，来设置自己滑动窗口的初始值。

如果我的接收缓冲区大小为0，怎么办？
很简单，不发数据了，等待缓冲区被刷新

拥塞控制

 我们之前考虑的全是两端主机之间的问题，并没有考虑到中间网络的影响。
滑动窗口就是针对两端主机数据传输问题所开发的机制，但是数据传输过程中如果遇到网络比较拥堵的问题，在不清楚当前网络状态情况下，贸然重发数据，很有可能雪上加霜，所以拥塞控制是TCP发现网络拥塞，尝试恢复网络状态的一种策略。

TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。

• 此处引入一个概念程为拥塞窗口，它是一个描述网络可能会发生拥塞的临界值(就是一个整数)。
• 发送开始的时候, 定义拥塞窗口大小为1。
• 每次收到一个ACK应答, 拥塞窗口加1。
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口。

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

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍。
• 此处引入一个叫做慢启动的阈值。
• 当拥塞窗口超过这个阈值的时候。不再按照指数方式增长, 而是按照线性方式增长
• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值。
• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。
  

为什么叫做慢启动指数级增长？
指数级增长，前期慢，一旦过了某时间点后，增长就特别快。前期慢也非常符合我们要求的：发送少量报文探探路，前面的两三次探测，发现都会给我应答，说明网络已经就绪了，我们此时不应该慢下去，而应该快速的恢复出来。所以指数级增长，既保证了不要在前期把网络压垮，又要保证检测网络没有问题，我们尽快恢复网络状态。

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

延迟应答

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

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

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率！
那么所有的包都可以延迟应答么? 肯定也不是！

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

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

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说 “吃了吗？”，服务器也会给客户端回一个 “嗯，吃了！”+“你吃了吗”; 那么这个时候ACK就可以搭顺风车, 和服务器回应的 “嗯，吃了！你吃了吗” 一起回给客户端。

重新认识三次握手：

实质上是4次握手！将中间两次压缩成一次。

面向字节流

 TCP中的流，指的是流入到进程或者从进程流出的字节序列。面向字节流的含义是，虽然应用程序和TCP的交互是一次一个数据块(大小不等)，但是TCP把应用程序交下来的数据仅仅看成是一连串的无结构字节流，TCP并不知道所传送的字节流的含义。

在应用层创建一个TCP的socket，本质在内核中创建一个发送缓冲区和一个接收缓冲区。

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

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

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

粘包问题

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

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

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

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

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

所以UDP协议是不会出现粘包问题的。

TCP异常情况

1️⃣进程终止：进程终止会释放文件描述符, 仍然可以发送FIN。和正常关闭没有什么区别。
2️⃣机器重启: 和进程终止的情况相同。
3️⃣机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了, 就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放。
4️⃣另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中, 也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接。

TCP小结

可靠性：

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

提高效率：

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

其他：

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