TCP 一网打尽（握手挥手消息头格式滑动窗口阻塞控制）

2019-02-15 本文已影响16人黄靠谱

概述

三次握手：

Client：SYNC，seq 客户端尝试连接Server端
Server：Ack，SYNC、seq 服务端响应客户端的Sync请求，并且服务端向客户端也发起Sync请求
Client：Ack，seq 客户端响应服务端的Sync请求

四次挥手：

客户端发起FIN请求
服务端响应FIN请求
服务端完成所有数据传输，向客户端发起FIN请求
客户端响应服务端的FIN请求，并且2MS后，断开连接

TCP为了维护连续请求数据的有序性，SYN链接的时候随机本地生成一个 seq=x，后续第二次seq=x+1，第三次seq=x+2，这样可以发现是否有数据丢失。
一个完整的数据在网络之间传输：IP消息头（数据源IP 和目标源IP）+TCP消息头（消息源端口目标源端口等等） +TCP Data

image

TCP消息头格式：想想TCP3次握手、4次挥手，很多内容就可以联想到了

image

源端port、目标端Port（IP地址是归上层管的，和TCP无关)
Seq、Ack （记录请求序号、响应序号）
标志位： FIN、SYNC、RST 标志TCP的包的状态
windows：滑动窗口，用来做流量限制，接收方告知发送方自己的能够提供的缓存区的剩余大小，避免发送方把自己流量刷爆掉
header length：消息头的长度，因为可能包含 option内容，所以长度不是死的
options：做选择重传的时候，可能会用到这个字段
校验位(Checksum)：CheckSum是根据伪头+TCP头+TCP数据三部分进行计算的，可以保证数据的接收完整，不然计算出来的值就不一样，类似于MD5

重传机制：超时重传、快速重传、选择重传
https://www.jianshu.com/p/f0920bb9a179

超时重传：接收端当接收的数据Seq不连续的时候是不会Ack对应的Seq，从而保证数据的完整有序，当发送端超时未收到Ack，会根据策略选择部分重传或者全部重传。此时timeout的设置和重传策略非常关键。
快速重传：不基于timeout的重传机制，接收端如果发现消息不连续，会反馈问题数据的seq，当发送端统计超过3次时，就会重传，接收端会缓存住收到的消息。快速高效的一种解决方案

image
选择重传：接收端通过Ack的消息头Options存储已经接受的消息和丢失的消息，Ack给发送端，发送端根据记录信息，选择性的重传丢失的数据包

滑动窗口（windows)
[站外图片上传中...(image-783ca1-1550228876420)]

是TCP消息头里面的一部分，用于接收方通知发送方自己还有多少缓冲区可以接收数据。发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，是谓流量控制。
每个TCP的发送端和接收端都有一个缓冲区，缓冲区有指针，自己的发送和接收的情况
服务端通过控制分配给不同线程的缓冲区的大小来做流量控制，防止自己被客户端把流量刷爆掉
接收方的缓冲区是可以有空白区，预留给那些Seq不连续的消息，这个机制既可以保证消息的严格有序，又具有一定的容错性，如果中间有个消息延迟抵达，也不会影响到提前抵达的下面的消息，只要最终消息是连续的，都可以保证消息整体最终有序
发送方：LastByteAcked指向收到的连续最大Ack的位置；LastByteSent指向已发送的最后一个字节的位置；LastByteWritten指向上层应用已写完的最后一个字节的位置。
接收方：LastByteRead指向上层应用已读完的最后一个字节的位置；NextByteExpected指向收到的连续最大Seq的位置；LastByteRcvd指向已收到的最后一个字节的位置。可以看到NextByteExpected与LastByteRcvd中间有些Seq还没有到达，对应空白区。

拥塞控制

慢启动：阻塞发生前采取，对于刚刚加入网络的连接，启动时限制可发送包大小，然后指数增长到阈值，ack确认一个增长一些，再线性增长，防止一连接就大量包。如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。如果当前网络不佳，Ack比较慢，缓冲区大小增长的也慢，可以实现错峰限流的功能。
Nagle算法：发送端缓存满一个ack包时再发送，避免小包
Cork算法：当滑动窗口值小于某值时，停止发送，一直到接收端调整到该阈值时才允许发送

OSI计算机网络通信架构

OSI模型把网络通信的工作分为7层，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

应用层：面向用户的一层，比如用户上网（http协议）、用户发邮件(SMTP）协议
表示层：数据格式转化、加密（比如编码格式、加密操作)
会话层：负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
传输层：建立了主机端到端的链，端就是端口，TCP UDP就是这一层
网络层：本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层
数据链路层：字节、比特、流转换
物理层：物理介质相关

功能和原理

提供数据可靠完整(TCP）且在全球局域网(IP)中数据传输的机制。
封装了Scoket接口来实现TCP/UPD传输。
TCP属于传输层，提供可靠的字节流服务，将大块数据分割成以报文段（segment）为单位的数据包进行管理。TCP 协议为了更容易传送大数据才把数据分割，而且 TCP 协议能够确认数据最终是否送达到对方。

TCP与UDP区别总结：

http://blog.csdn.net/xiaobangkuaipao/article/details/76793702

TCP面向连接（如打电话要先拨号建立连接）确认信号互相通畅;UDP是无连接的，即发送数据之前不需要建立连接
TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达，发送有个确认的过程;UDP尽最大努力交付，即不保证可靠交付
Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
TCP对系统资源要求较多，UDP对系统资源要求较少。

TCP与UDP的区别与适用场景

TCP协议栈本身是可靠，不会丢包，不会乱序，失败会重发。UDP需要应用层做协议来保证可靠性。视频可以用UDP。
必须使用udp的场景：广播。

长连接、短连接

http1.0默认短连接，每次交互都需要三次握手收到消息后四次挥手，而且加载 js、css文件的时候也要重新重复创建链接。http1.1支持设置允许长连接。
长连接：连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）；这就要求长连接在没有数据通信时，定时发送数据包(心跳)，以维持连接状态；
长连接多用于操作频繁（读写），点对点的通讯，而且连接数不能太多情况。一般web请求都是短链接，游戏都是长连接，QQ