接上一篇：【网络知识面试】初识协议栈和套接字及连接阶段的三次握手
 前面我们了解到服务器和客户端在创建套接字，建立连接后，就可以进入到下一步，双发可以互相发送和接收数据，本篇博客就来学习一下这个过程。
 我们印象里，发送数据应该是我们在浏览器输入网址，敲击回车的一瞬间，发送动作就完成了，回头服务器处理完成将数据发送客户端，浏览器解析出来，这就是反过来接收的过程。

1. 发送数据

 由浅入深，了解这个大体过程，我们先来看看发送数据的简单过程。对于浏览器，他没有办法直接向网络中发送数据，而是要将http请求委托给协议栈（操作系统的网络控制软件）来发送。但实际上，在计算机中，并不是只有浏览器会发送网络请求，QQ、微信等很多应用程序都会执行这个动作。所以协议栈工作就是会接收各种应用程序发送过来的网络请求数据，其实就是一堆的二进制字节数据。
 协议栈在拿到数据后，是不是会直接发送到网络中的，必然不是，他在内部会维护一段内存缓冲区，等待下一段数据，然后在某个合适的时机再发送出去。这块内存就是发送数据的专用缓冲区。当然，接收数据的时候也是有一块专用内存的，后面我们再说这个。这里还提到了，合适的时机发送数据，这个时机是根据两个要素来判断的，我们看看是哪两个哦。

1.1 网络包长度

 第一个因素是跟网络包长度相关的，什么意思呢，对于某些GET请求，要发送的请求内容必然很少，一个网络包就能放得下，但是有些POST请求，比如我要写的这篇博客，经过编码解析，需要很多歌网络包才能放的下，这里就涉及到拆包的概念。

 这里先了解两个网络词汇：MTU，MSS

• MTU： 指的是一个网络包的最大长度，以太网中通常是1500个字节。
• MSS： MTU中去掉头部之后，所能容纳的数据的最大长度。

 了解这两个概念，我们在来看下上面说的拆包的概念，即我们发送的某次网络请求，可能是通过1个网络包发送给服务器的，也可能是很多个，决定因素就是MTU和MSS。

 在应用程序将数据发送给协议栈的时候，数据可大可小，协议栈无法决定，如果每次接收到应用程序的一次数据就立即发送出去，必然会导致发送大量小的网络包，网络效率下降。所以，协议栈一般会累积到数据量可以塞满一个网络包的时候再发送出去，即MTU的长度，这就是第一个决定协议栈发送数据的因素。

1.2 发送时间

 决定协议栈 发送数据的第二个因素是时间，为啥呢？我们可以试想一下，如果GET请求的数据长度无法达到一个MTU的长度，协议栈一直等待到一个网络包的数据长度再发出去，必然会产生很大的延迟，给我们卡顿的感觉。所以，某些情况下，即便网络包没有被填满，也会立即把数据发送出去。
 协议栈内部会维护一个计时器，在超过设定的时间阈值后，即便没有达到一个完整网络包数据长度，也会立即发送。一般，这个时间是由协议栈的开发者决定的，不同操作系统的不同版本会有不同实现。

 其实，决定协议栈发送数据的这两个要素，在某些情况下是比较矛盾的，立即发送会导致网络效率下降，等待太久又会造成延迟。过分依靠协议栈来决定发送时机会带来一些问题，所以协议栈也给了应用程序一个选项，来决定是否立即发送。像浏览器这样的会话型应用程序，一般会选择“立即发送”的选项。

2. 确认发送成功以及重发功能的实现

 TCP协议的非常重要的功能就是可以确认通信的一方是否已经成功收到了网络包，如果没有收到，必须具有重发的功能。这个功能的实现就是借助于ACK号和seq序号要进行对方接收确认的操作。

 上文我们说过，在网络请求内容过大的时候，TCP会有拆包的逻辑，那么在拆分的过程中，TCP就会计算好并记录每个网络小包在整个请求内容中处于第几个字节，然后再发送网络包的时候，在TCP头部记录这个字节数（就是seq序号，比如目前是第1个字节），服务器在接收到网络包的时候，会读取这个字节，然后再计算这个网络包MSS的长度（比如网络包数据长度是1000），在确认回复的时候，会将ACK赋值为ACK = 1 + 1000 并返回给客户端。客户端在接收到ACK号的时候就可以确定网络包已经顺利被对方接收，否则就会重试发送。

 我们可以想象一下，客户端在发送下一个网络包的时候，一定是从第1001个字节开始的，于是服务器在收到请求后，可以顺便验证1001是不是和自己最后一次ACK响应的字节数相等，如果相等说明中间没有丢包，如果是2001，说明中间丢失了至少一个网络包。

 这里我们已经提到了ACK和seq，TCP协议可以通过ACK号和序号就可以确认对方是否收到了网络包。我们来看一个虚拟的例子加深一下了解。

2.1 调整ACK号等待时间

 我们的网络传输并不是一帆风顺的，发生拥塞和抖动的情况是非常常见的。前文我们提到TCP会通过ACK号确认对方已经接收到网络包，但是在网络比较慢的情况下，发送和接收ACK号的平均响应时间就会比较长了，如果客户端在这个时候设置了比较短的等待时间，就会在没收到ACK的情况一直向以太网中发送数据，这对于本来已经繁忙的网络就更加糟糕了，这其实就是TCP的网络包重传。

 通常，当网络包重传发生后，有可能前一个相同网络包的ACK号才返回，这样的重传其实是不必要的。所以，对于等待时间来说，需要设置一个合适的值，这个时间应该是可以动态调整的，而计算方法就是根据过往发送数据的过程中，持续监测ACK号的响应时间，如果ACK号的返回时间变慢，就会响应延长这个等待时间，否则就缩短等待时间。

 除此之外，TCP还是使用了滑动窗口的方式来管理数据发送和ACK号的管理，大体思路就是第一个网络包在发送出去之后，并不是等待当前网络包的ACK号返回才发送下一个，而是直接发送下一个，或者说是下面一系列的网络包，这样的话，发送的等待时间就会被有效的利用起来了。这个过程相对复杂一些，涉及到窗口大小的概念，这个窗口大小就是指接收方网络协议栈中，在当前时间里，剩余的最大缓存空间，也就是能接收的字节数。下图就可以看出来一来一回和滑动窗口的方式，这里不再深入展开，可以查看相关资料。

3. 接收数据

 在客户端发送完数据的过程后，服务器端就可以接收并处理网络包了，对于单个网络包的处理比较简单，对于客户端拆分后分多次发送的网络包，服务器的TCP协议同样会以相同的方式拼接起来转换成为对应的网络请求，其实就是和客户端处理相反的方式进行的。服务器在处理请求后，就会将相应数据发送给客户端。

 我们可以想一下，客户端的浏览器程序在委托协议栈发送了网络请求后，就处于等待响应结果的状态。这个状态其实是浏览器调用了Socket组件库的read()函数，协议栈会将这个工作挂起，直到服务器数据相应之后，协议栈写入到接收缓冲区中，在这个过程之前，接收缓冲区一直是空的，浏览器就无法处理数据，这个挂起就是我们常说的阻塞过程。这个如果继续延伸的话，会有阻塞式IO，非阻塞式IO，IO多路复用等知识点，在此不深入。

 总结一下这个过程，客户端的协议栈会检查接收到的数据和TCP头部的内容，判断是否有数据丢失，如果没有问题会向服务器返回ACK号。然后协议栈将接收到的数据暂存到接收缓冲区（这个缓冲区是协议栈的）中，然后将数据块按照顺序连接起来还原成原始的数据，最后将数据交还给应用程序，其实是把协议栈缓冲区中的数据复制到浏览器制定的内存地址中，然后浏览器去解析的过程（这个过程还是在read里面实现并把控制流程交还给浏览器的）。

4. 断开连接

 接下来最后一个流程，就是数据发送完成之后的断开连接了，那么断开连接这个操作是由客户端还是服务端发起的呢？
 在协议栈中并没有规定哪一方应该先发起断开操作，通常是由应用程序判断自己的数据已经发起后就可以发起断开动作了。比如我们访问web服务器，发送请求，服务器接受请求处理完成会向客户端返回数据包，等到所有数据都返回了，服务器会主动发起断开操作。下面，我们就以这个例子，服务器先发起断开操作理解这个过程。

 所谓的断开操作也是由发起方调用Socket库的中close()程序实现的，在这个方法中，协议栈会生成包含了断开控制信息的TCP头部，具体来说就是将FIN比特位设置1，然后再委托IP模块将数据发给客户端，接下来，服务器套接字中就会记录下断开操作的相关信息。

 接下来看我们的客户端，在接收到FIN比特位为1的包时，客户端知道了，噢服务器要断开连接了，那好在自己的套接字中标记一下要进入断开操作了，记住这里只是标记一下，同时必须要返回服务器ACK号，告知服务器已收到FIN=1的断开网络包了。

 然后，待到客户端协议栈接收缓冲区数据被应用程序全部取走之后(前面讲到的应用程序的read()操作)，客户端感觉时机成熟了，也会向服务器发送一个包含FIN=1头部的网络包，服务器同理也要返回ACK包，至此，双方的通讯正式结束。

5. 删除套接字

 接下来断开操作的最后一步就是删除套接字，这里尤其注意用来通讯的套接字不会立即删除，而是会等待一段时间后再删除，具体原因如下：

 我们现在举个跟上面相反的断开的例子，由客户端发起断开请求：

• 客户端发送FIN=1包
• 服务器返回ACK号
• 服务器发送FIN=1包
• 客户端返回ACK号

 这里特别注意最后一步，客户端在返回ACK号之后，如果立即删除套接字会发生什么呢？正常情况，可能是服务器收到客户端的ACK号双方通讯结束没问题。但是如果因为网络拥塞问题，服务器没有在规定时间收到第四步的ACK号，那么服务器又发送了一次FIN=1，这里可能会有问题了，因为客户端已经删除了套接字，此时如果恰巧又其他应用程序请求连接服务器并且创建了相同端口号的套接字，那么这个新创建的套接字因为收到了一条莫名奇妙的FIN=1就要进入断开操作了，就会有问题了。所以客户端并不会立即删除套接字，就是为了防止这个问题发生。
 通常，这个等待删除套接字的时间就是几分钟而已。

6. TCP的整体流程