一、前文回顾TCP 是 有链接面向字节流可靠传输全双工全双工就是可以读也可以写像双向车道单双工是只可以读或者值可以写像单行车道。这是TCP 协议的传输结构。二、部分解析2.1 16位源端口和目的端口网络传输的五件套源 IP、源 端口、目的 IP、目的端口、协议类型。源端口和目的端口是传输层的核心内容。2.2 四位首部长度这是标识TCP 头部占多少字节告诉接收方 TCP 头部从哪结束、应用数据从哪里开始。只是这么长就会导致TCP协议和UDP协议一样表头受到限制但是TCP中还有选项卡和保留位可以扩展这个首部的长度就不会像UDP那样窘迫了。2.3 保留位因为有了UDP的报头长度受到限制的问题预留的长度不够而且还不能扩展所以 TCP 在设计的时候就提前保留了保留位这个位置先不用先占个位置。2.4 6个标志位URG是紧急位这个位置用来标记当前数据是不是紧急数据是否需要优先处理。可以用来中断、紧急指令等...ACK是确认位用来确认号是否有效它是响应的标志位这个位置设置为1就是用来响应的数据。PSH推送位让接收方不要缓存直接把数据给应用层RST复位位强制断开连接或者重置异常连接。SYN同步位请求和服务器建立连接同步序列号。FIN结束位请求正常关闭连接。2.5 校验和用来验证数据是否出现错误。三、 TCP 核心机制 可靠性因为网络通信是非常复杂的这里的可靠性不是100%传输到对方。而是 A 给 B 发了信息之后尽可能的让 B 收到并且 A 是能够知道 B 是否收到了。3.1 核心机制一确认应答保证可靠性的一个关键前提就是发送方得知道接收方是否收到了数据这时候就需要接收方在接收到发送方发送来的数据之后给发送方发送一个“确认收到”的响应发送方在收到这个应答报文之后就知道这个数据传输过去了。而且网络是很复杂的也会存在后发先至的这种情况这时候如果A给B发送两个请求分别是1请求2请求在网络中可能会出现先发送的A后发送的B但是先到达的是B后到达的是A。这时候 TCP 就会在对方的缓存那里开辟一段空间让这两个数据报先到达的话先停在那里先不去解析请求发送响应所以这时候 B 先到了就会来等 A 到之后再一起去让服务器解析请求。怎么完成的呢在传输的时候给这两个请求进行编号存放在两个 TCP 的数据报中这样接收方解析 TCP 数据报的时候就知道了这次传输有多少个数据这些数据的前后顺序也都会知道。TCP是面向字节流的在编号的时候不是直接按照1条2条这样的方式来进行编号的而是按照 “字节” 来编号每个字节都分配一个编号这个编号连续递增。就像下面的流程引入序号之后接收方就可以根据序号对数据进行排序。这样就能处理后发先至这种情况了。因为TCP处理后发先至这种情况所以确保了应用程序通过soket api 读到的数据顺序是正确的即使出现了后发先至这种情况TCP 也会帮我处理掉确保了代码中独到的数据和发送方写入的数据顺序是一致的。TCP 报头是不参与编号的。序号和确认序号都是针对数据(也就是载荷)来说的。什么方式来处理后发先至这种情况呢TCP在接收方这里会安排一个“接收区缓冲区”(内存操作系统内核里)通过网卡读到的数据先放到这个接收缓冲区里面接收方后续的代码调用 read 也是从这个接收缓冲区来读取数据的因为TCP又给这些发送的数据进行了编号所以在这里就能根据编号来进行排序了。如果前面的数据还没来后面的数据都来了而且接收方还开始了 调用 read 接口来读取数据此时 read 就会发送阻塞直到前面的数据已经来了才会释放阻塞。因为一个数据如果太大了那一次网络传输肯定是传输不了的这时候就是上面的分开传输那这种分段传输为什么不害怕黑客窃取篡改导致数据的不完整吗因为路由器这边也是可以处理 TCP 的也会有接收缓冲区也会进行排队所以可以确保路由器上的应用层数据报是完整有序的。3.2 TCP 核心机制二超时传输数据在进行网络传输的时候难免会丢包。丢包原因有很多就像数据报经过某个路由器交换机的时候该路由器/交换机上的业务已经很多了没有能力再处理我们发送的数据报了这时候就超出了当前路由器/交换机的转发能力上线就会导致我们的数据报被丢弃或者是等待很长时间所以 TCP 就引入了超时时间来判断当前是否丢包。有这两种情况情况一是数据报丢了这时候因为一直没有接收到确认接受数据报也会触发超时重传可以解决问题。情况二是服务器的响应丢包了这时候由于客户端没有接收到响应数据也会出发超时重传操作所以是否超时重传也是根据是否接收到响应应答这个数据报来说的。那万一一直丢包呢TCP 会无限时间重传吗答案是不会的发生一次丢包之后发送方会认为该路径上的某个路由器/交换机可能会比较繁忙会延长这个超时时间当尝试的次数达到一定的次数/等待的是时间到一定的程度就会认为当前网络出现严重的故障就会放弃当前这一次传输。因为丢包是一个小概率事件所以随着重传的次数的增加丢包的概率也会相应的减少很多次重传之后都没收到响应信息就意味着网络大概率出现严重故障这时候重传也没办法到达对面这时候就会放弃当前任务。四、三次握手根据上面的交互都是一个请求一个响应为什么到建立连接这里就变成了三次呢一般情况下应该是客户端发起连接服务器接收连接发送响应然后服务器发起连接客户端接收连接发送响应这应该是四次交互就像下图。直接把四次交互变成了三次交互。因为在服务器发送第一个响应的时候只要数据包中 ack 这个选项勾选上再把 syn 这个选项也勾选上而且这个数据就只有两个数据一个接收连接一个发起连接所以可以合并在一起。4.1 为什么要三次握手三次握手是可以确定双方的接收和发送都没问题第一次客户端发请求给服务器这时候服务器接收到请求就确定服务器接收数据正常然后服务器构造响应和给客户端发起连接这时候确定了服务器端请求是正常的(这时候客户端发送正常、接收不确定服务器接收正常、发送不确定)然后客户端接收到服务器发起的连接之后给服务器发哦是那个一个 ack这时候服务器接收到这个ack就能确定了双方的通信(接收和发送)都是正常的。而且在这个三次握手的过程中是可以相互协商一些关键的信息的TCP 要协商的一个非常关键的信息就是通信过程中序号从几号开始。所以初始序号一般都不是从0开始的。并且两次连接的初始序号都是不同的。也就是当服务器其中一个连接在路中迷路了然后后面又重新发送的连接被客户端接收这时候服务器就和客户端建立好了连接然后过了一段时间这个迷路的连接找到了客户端这时候客户端已经和服务器建立好了连接所以这个连接在到达客户端的时候就知道了它是迷失的数据报就会被丢弃继续保持当前连接