三次握手齐白首，四次挥手说分手
本篇博文其实并不只是学习三握手四挥手，而是总结计网传输层的内容，只是这八个字在传输层中地位实在太重了…故单列出来做标题，当然，你耳熟能详的滑动窗口这里也会涉及到
传输层之下的层之前也已经写了…推荐你阅读
三言两语轻松计算机网络入门
走进科学之-计算机网络物理层-硬核扫盲
走进科学之计算机网络-数据链路层-硬核扫盲
计算机网络-网络层-详细总结
说起来TCP的连接与释放真是个浪漫的故事呢！~
文章目录
- 三次握手齐白首，四次挥手说分手
- TCP/IP协议概述
- 传输层协议的作用体现在应用层协议
- TCP/UDP传输层协议与网络层协议的区别
- UDP协议
- TCP协议
- TCP协议确保可靠传输
- 滑动窗口
- TCP流量控制
- 三次握手齐白首
- 四次挥手说分手
TCP/IP协议概述
在TCP/IP协议栈，传输层有两个协议TCP和UDP
TCP（Transmission Control Protocol，传输控制协议）协议：负责将要传输的文件分段 进行传输，一般用于建立会话 ，其基本特性是可靠传输 、流量控制，所谓三握手、四挥手也是基于TCP协议的
UDP（User Data Protocol，用户数据报协议）协议：一个数据包就能够完成数据通信 ，数据包不分段 ，不需要建立会话 ，不需要流量控制 ，属于不可靠传输 ， 屏幕广播 、多播 、广播都是基于UDP协议
以上定义，下面来详讲
传输层协议的作用体现在应用层协议
TCP和UDP协议内指定不同的端口即可对应一个应用层的协议
端口代表主机服务的侦听"门牌号"，不管是TCP还是UDP，带上门牌号，它就能帮你找到主机上的对应服务
例如我们在浏览器访问某个网站地址，这个动作会被我们本机上的80端口侦听到，并处理你的网络请求
我们主机上常见的应用层协议端口：
- HTTP默认使用TCP的80端口标识
- FTP默认使用TCP的21端口标识
- SMTP默认使用TCP的25端口标识
- POP3默认使用TCP的110端口
- HTTPS默认使用TCP的443端口
- DNS使用UDP的53端口
- 远程桌面协议（RDP）默认使用TCP的3389端口
- telnet使用TCP的23端口Windows访问共享资源使用TCP的445端口
但是我们通过TCP/UDP封装的数据包，通过本机侦听服务发送到目标主机，目标主机是如何识别并处理的呢？
如上图，我们会在数据包中添加目标端口号，这样目标主机相关服务侦听到，就能处理我们的请求了
TCP/UDP传输层协议与网络层协议的区别
- 网络层实现如何把数据包从这个地址(服务器)发送到另一个地址(服务器)
- 传输层实现如何让这个应用程序找到对应计算机的应用程序，即服务
说白了，IP协议主要让数据能知道传到哪去，不管对应目标谁来负责接待，而TCP/UDP管
越靠近顶层应用层、功能越强大
UDP协议
主要特点：
- UDP 是面向无连接的，即发送数据之前不需要建立连接，如向DNS服务器申请域名解析服务
- UDP 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制
- UDP 是面向报文的。UDP 没有拥塞控制，很适合多媒体通信的要求
- UDP 支持一对一、一对多、多对一和多对多的交互通信，这也是，应用场景如广播、组播
- UDP 的首部开销小，只有 8 个字节
基本描述：
UDP首部
首先得知道数据包在OSI模型中层层传输，自顶向下
来看看UDP首部
- 用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是两个字节
- 在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和，伪首部12个字节取自IP数据报的字段
- 检验和实现UDP数据检验，通过验证检验和可以知道UDP数据包是否出现异常
TCP协议
基本特点：
TCP 是面向连接的传输层协议，UDP面向无连接
每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一）
TCP 提供可靠交付的服务（持续交付）
TCP 提供全双工通信（信道双向传输）
面向字节流(传送最小单位为字节，即八位)
上图可以看出TCP传输是如何面向字节流的，具体细节后面继续解析
TCP连接基于Socket：
TCP 把连接作为最基本的抽象，每一条 TCP 连接有两个端点
TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是传输层的协议端口。TCP 连接的端点叫做套接字(socket)
IP地址+服务端口构成了套接字
TCP协议确保可靠传输
TCP使用自动重传请求ARQ (Automatic Repeat reQuest)确保可靠传输
停止等待机制:
报文过不了检验的，被B丢弃，A发送发出去的报文无回应、重新发送
请注意：
- 在发送完一个分组后，必须暂时保留已发送的分组的副本，方便重传
- 分组和确认分组都必须进行编号
- 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些
确认丢失和确认迟到机制：
- 确认丢失机制将超时的包覆盖为超时重传的包
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
ARQ 表明重传的请求是自动进行的
TCP流水线传输：
停止等待协议的优点是简单，但缺点是信道利用率太低
改进:
发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认，由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率
连续 ARQ 协议(自动重传协议):
连续ARQ（Automatic Repeat reQuest）协议指发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有分组都可连续发送出去，而中途不需要等待对方的确认。这样信道的利用率就提高了。而发送方每收到一个确认就把发送窗口向前滑动一个分组的位置
接收方一般都是采用积累确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了
积累确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息
例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只是对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响
TCP 报文段的首部格式:
- 源端口和目的端口字段各占 2 字节(16位)，源端口指发送端相关服务端口，目的端口是目标主机相关服务，端口是传输层与应用层的服务接口，传输层的复用和分用功能都要通过端口才能实现。
- 序号：当前数据组的第一个字节在整个文件中的序号
- 确认号ack：接收端发送，提示发送端下一次该发的数据在整个文件中的序号（收发连续的话就是序号+1），接收端收到后，会把这个序号之前的数据从缓存中删掉
- 数据偏移：指明当前TCP报文段第多少个字节后是TCP的数据部分了，数据偏移最多表示1111，即15，他最多可以表示15乘以4，即60个字节的偏移量，所以选项+填充最多只能是40个字节
- 保留：就是保留，没有用的
- URG：urgent，意思是优先级高，发送端优先发送，而不是在缓存中排队
- ACK：acknowledge，1意味着确认正式建立了会话
- PSH：1意味着接收端优先读取，而不是在缓存中排队
- RST：reset，1意味着TCP会话出现严重错误，必须释放和重新连接，比如你打开网页又立马将之关掉了，那么接收方也不用再给你传输网页信息了
- SYN：同步，1意味着要发起会话
- FIN：finish，1意味着释放连接
- 窗口：同步接收端和发送端窗口大小的，接收端先发，发送端根据接收端的窗口尺寸确定发送端窗口尺寸
- 检验和：略，上已讲
- 紧急指针：只有URG为1才有用
滑动窗口
TCP 可靠通信的具体实现：
- TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口
- TCP 的可靠传输机制用字节的序号进行控制
- TCP 两端的四个窗口经常处于动态变化之中
- TCP连接的往返时间 RTT 也不是固定不变的，需要使用特定的算法估算较为合理的重传时间
窗口动态变化-以字节为单位的滑动窗口：
- A的发送窗口是由B的接受窗口长度决定的
- 在没有收到B确认收到之前，A不能删掉滑动窗口内的内容
- A可以持续给B发送，直到A的滑动窗口内数据都发送成功
- B收到后给A发确认收到的反馈ack（下一个应该发送的字节的序号），A收到后，就可以滑动窗口到对应的位置。例如B反馈ack是7，那么A的滑窗可以移动到7位置，1-6删除，21-26可以继续发送
相关名词：
P3 – P1 = A 的发送窗口（又称为通知窗口）
P2 – P1 = 已发送但尚未收到确认的字节数
P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口
TCP流量控制
流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制，收方返回的 rwnd中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送，发送方在rwnd窗口之后的数据不允许发送
流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面
死锁解决：
接收方返回窗口大小为0，可能是缓冲区已满，需要处理缓存中的字节，发送端收到滑动窗口为0，不再发送，但是数据还没发送完，这就造成了死锁
如果在某个时候，接收方缓冲区有空间了，于是发送了一个非 0 窗口的通告给接收方，不幸的是这个通告丢失了，而发送方却还在死等接收方的非 0 窗口通告，接下来就成了死锁
TCP 为每一个连接设有一个持续计时器
若持续计时器设置的时间到期，就周期性的向接收方发送 1 字节的 0 窗口探测报文
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器，等待重传
若窗口不是零，则死锁的僵局就可以打破了
三次握手齐白首
传输连接有三个阶段，即：连接建立（三次握手）、数据传送和连接释放（四次挥手）
头两次握手除了确定双方都能联通外，还通知了双方的一些端口信息
A：我们谈恋爱吧
B：好的（如果“好的“丢了，A就不知道B的态度，感情就无法建立起来）
C：走你~
第三次握手原因：假如把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定A给B发送一个连接请求分组，B收到了这个分组，并发送了确认应答分组。按照两次握手的协定，B认为连接已经成功地建立了，可以开始发送数据分组。可是，B的应答分组在传输中被丢失的情况下，A将不知道B是否已准备好，A认为连接还未建立成功，将忽略B发来的任何数据分组，这样就形成了死锁
四次挥手说分手
A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP
连接A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认（A：分手吧？）
B 发出确认，确认号 ack = u + 1，而这个报文段自己的序号 seq = v（B：确定吗？）
TCP 服务器进程通知高层应用要进行关闭了
从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收（因为A要知道B是否收到断开请求）
若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接，并通知A连接已关闭（B:那就分了吧，我走了）
A 收到连接释放报文段后，必须发出确认(好的)
