建立连接大致流程：
1.协议栈根据上层传递的服务器ip端口确定 要链接的服务器sicket， 填充tcp头部信息（发送接受方ip端口信息）并将syn设置为1,修改的socket状态为正在连接
2.委托ip模块发送给服务端的ip模块，在给到tcp模块 服务器根据头部信息找到要链接的socket 填入对应的客户端ip端口 然后再创建tcp头部信息（发送和接收方ip端口）还有syn报文值为1（代表链接成功）除此之外再返回一个ack等于1的报文（代表网络包和序号都收到）委托服务器ip模块发送（建立连接的确认过程文末讲解）
3.客户端收到后完善socket中的服务端ip地址端口信息，判断服务端返回的syn是否为1来确定是否链接成功 接着设置socket状态为连接完毕；最后 向服务端模块在发送一个ack报文1确认网络包收到（tcp头部信息还是必须要填写的）
协议栈何时发送数据～
建立连接后应用就可以和服务端进行通信了，应用发的数据会缓存到协议栈中，但是何时发送呢？有两种情况，下面介绍
数据长度
应用可以指定发送数据的大小，如果协议栈收到发送指令就进行发送的话，不可控而且效率低；因此协议栈内部会指定一个长度，当达到长度后在进行发送，此前发送的数据保存到缓冲区中。
这个长度就是mtu（包含了tcp，ip，mac等头部控制信息）；除去网络包的头部信息后叫做真实数据的最大传输单元，叫做mss。
MTU:Maximum Transmission Unit，最大传输单元
头部信息是固定长度，因此mtu可知，既mss可知
MTU：一个网络包的最大长度，以太网中一般为1500字节。
MSS：除去头部之后，一个网络包所能容纳的TCP数据的最大长度。
发送频率
除了考虑数据长度外，还有一个因素要考虑，就是应用发送数据的频率。
应用程序发送数据的频率不高的时候，如果每次都等到长度接近MSS时再发送，可能会因为等待时间太长而造成发送延迟，这种情况下，即便缓冲区中的数据长度没有达到MSS，也应该果断发送出去。为此，协议栈的内部有一个计时器，当经过一定时间之后，就会把网络包发送出去。
大致流程：
因此上层应用程序发送的数据会放到协议栈的缓冲区中，当满足上面两个因素条件之一时（应用程序也可以指定是否立即发送数据还是按照协议栈的规则判断时机）就可以发送数据了，首先切割mss为单位的数据块，在每个数据库开头都加上头部控制信息：
拆分示意图：协议栈负责添加tcp头部信息，接着委托ip模块发送消息，ip模块会添加ip头部和mac头部信息
网络包序号～利用syn拼接网络包ack确认网络包完整
上面说过网络包会拆分，那么服务器是怎么知道该怎么拼接这些网络包还原成最初的数据呢？答案是通过序号
确定偏移量
当拆分数据拼接成网络包的时候，会将这块数据相对于起始数据的偏移字节算出来携带到tcp头部；除此之外还会携带数据包的总长度
网络包的数据长度不是放到tcp头部中， 因为用整个网络包的长度（固定的mss）减去头部的长度就可以得到数据的长度，所以接收方可以用这种方法来进行计算。有了上面两个数值，我们就可以知道发送的数据是从第几个字节开始，长度是多少了。
服务器ack确定收到数据总长度
接收方会将到目前为止接收到的数据长度加起来，计算出一共已经收到了多少个字节，然后将这个数值写入TCP头部的ACK号中发送给发送方。
序号作用
序号的作用：上面的偏移量是携带到tcp头部中，很容易就会拿到自行还原数据破解的；因此在传递过程中每个包的数据长度都要进行基于某个值偏移，也就是将原来的偏移量要加上序号。
如第一个包默认的偏移量本来是0，序号值是666，那么现在添加序号之后第一个网络包的偏移量就是666
这样对方就搞不清楚偏移量到底是从多少开始计算的。
实现这种方式需要在开始收发数据之前将初始值告知通信对象。同样服务端也需要告知序号值这样客户端就知道该如何拆分。这个偏移量就是序号值
双端告知各自序号
那么什么时候把这个初始序号值发送给对方呢？
在发送连接的阶段中会将syn设置为1， 在将SYN设为1的同时，还需要同时设置序号字段的值，而这里的值就代表序号的初始值。这个syn就是通过告知序号值用于后面通信步调一致（知道每个网络包头部的偏移量是基于序号值+当前网络包相对于数据头部的偏移量），同样第二个阶段服务器返回syn1也是告知客户端之后发送包的序号值；同时发送ack数值告知客户端数据是否发送完整（需要利用客户端传过来的序号值，偏移量减去序号就是真正的偏移量了）；客户端收到后同样也需要向服务端发送ack来确认服务端发过来的数据是否完整（服务端发送syn1的时候将服务端的序号也发送了过来，也是用的这个序号来拼接服务端发送过来的数据）
这个就是大致的网络包拼接流程：
协议栈自动重发机制
自动重发机制：协议栈会在收到ack号确认之前中会存放发送的数据，如果某一个ack号没有发送过来就会重发这个数据。
大致流程
这样一来，无论网络中发生任何错误，协议栈都可以发现并采取补救措施（重传网络包） 。反过来说，有了这一机制，就不需要在其他地方对错误进行补救了。
因此，网卡、集线器、路由器都没有错误补偿机制，一旦检测到错误就直接丢弃相应的包。应用程序也是一样，因为采用TCP传输，即便发生一些错误对方最终也能够收到正确的数据，所以应用程序只管自顾自地发送这些数据就好了。不过，如果发生网络中断、服务器宕机等问题，那么无论TCP怎样重传都不管用。这种情况下，无论如何尝试都是徒劳，因此TCP会在尝试几次重传无效之后强制结束通信，并向应用程序报错
ack等待时间如何调整
ack等待时间也叫超时时间，如果协议栈发送数据等待ack的返回这段时间超过了超时时间，就会重新发送这个网络包。
但是网络信号是可以改变的，所以超时时间也应该和网络信号的好坏动态调整；并且网络信号差的时候不仅仅只是重发一个包这么简单后面的所有网络包都会收到影响（这个和安卓的anr排查差不多）
这个等待时间是根据ACK号返回所需的时间来判断的。具体来说，TCP会在发送数据的过程中持续测量ACK号的返回时间，如果ACK号返回变慢，则相应延长等待时间；相对地，如果ACK号马上就能返回，则相应缩短等待时间。
是否需要等待收到ack号后在发送数据～滑动窗口
现在的链路是 客户端服务端确认好端口ip后就开始通信了，客户端每次发送数据包携带数据长度信息 服务端返回ack信息确认是否完整收到（反过来也是一样的流程）
但是有个缺点 就是接收方必须等到发送方返回ack才能继续传输这会增加延时降低通信效率
所以采用滑动窗口的方式。客户端只管发送 不管是否收到ack报文 。
所谓滑动窗口，就是在发送一个包之后，不等待ACK号返回，而是直接发送后续的一系列包。这样一来，等待ACK号的这段时间就被有效利用起来了。
? ? 这样虽说提高了效率但是如果不等返回ACK号就连续发送包， 服务端的处理缓冲区会造成背压问题 （发送包的频率超过接收方处理能力的情况）。
发送的数据会存储在接收方的缓冲区中，之后取出来处理拼接ack号，如果什么都不管一直发送，缓冲区的数据会溢出，某些数据就会被放弃，这个肯定不是想要的结果。因此需要出一种机制能够知道对方缓冲区可以接受多少数据，根据这个值来判断是否继续发送，当服务器的缓冲区数据处理后，也需要告知客户端（通过tcp头部中的窗口字段）
图示：
合并ack号和窗口大小
如果接收方可以告知发送方当前可以容纳多少数据呢？发送方自己判断已发送的数据是不是到达极限从而暂停 当接收方处理数据时再通知客户端当前缓冲区容纳数据客户端在发送，这样是不是完美了？
并不是，如何确定ack和发送缓冲区数量的包呢？是分开发送吗还是合并 如果每次都携带缓冲区数量是不必要的 发送方知道后自己就可以判断是否达到缓冲区处理极限决定是否发送之后数据，那分开呢？又会降低效率 增加包的数量无疑会导致延迟效率下降
因此 这两个得合并但是不能每次都发，所以加了个延时的操作。
分为以下这几种情况
- 假如我等待发送ack数据时正好服务器处理了数据缓冲区容量更新需要通知到客户端这时候合并 就可以了。
- 再比如我处理完数据了 等待一段时间如果ack也要发送也用合并发送
- 并且如果需要连续发送缓冲区的数量时说明处理速度很快只要同步最后一次的缓冲区可用数量即可（比如200---400--600）等待一段时间发生减少包数量
- 需要连续发送ack时也是一样 说明客户端连续发送数据 接收方这边等待一段时间之后直接把刚收到的数据总和返回给客户端就行
通过延时解决合并不必要和独立数量多的缺点 具体延时根据实际情况判断（很多时候服务器处理速度很快几乎发送完数据就能立马处理完不需要缓冲区数量这个信息）
总结
协议栈会检查收到的数据块和TCP头部的内容，判断是否有数据丢失，如果没有问题则返回ACK号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。具体来说，协议栈会将接收到的数据复制到应用程序指定的内存地址中，然后将控制流程交回应用程序。将数据交给应用程序之后，协议栈还需要找到合适的时机向发送方发送窗口更新。