TCP 的特性
| 连接机制 | 无论哪一方向另一方发送数据之前，都必须先在双方之 间建立一个连接，否则将无法发送数据。 |
|---|---|
| 确认与重传 | 一个完整的 TCP 传输必须有数据的交互。 - 接收方在接收到数据之后必须正面进行确认，向发送方报告接收的结果 - 发送方在发送数据之后必须等待接收方的确认。 同时发送的时候会启动一个定时器，在指定超时时间内没收到确认，发送方就会认为发送失败，然后 进行重发操作 |
| 缓冲机制 | 缓冲机制是为为了缓冲数据量过大或过小造成的信道拥堵等问题。 数据量很小时： - TCP 会将数据存储在一个缓冲空间中 - 等到数据量足够大的时候在进行发送数据 数据发送方：不会立即删除数据，还是让数据保存在缓冲区中 【因为发送出去的数据不一定能被接收方正确接收，它需要等待到接收方的确认再将数据删除。】 在接收方也需要有同样的缓冲机制 【数据报到达的时间是不一样的，而且 TCP 协议还需要把这些数据报组装成完整的数据，然后再递交到应用层中。】 |
| 全双工通信 | 即接收方把确认信息放到反向传来的是数据报文中，不必单独为确认信息申请一个报文 捎带机制减少了网络中的通信流量。 |
| 流量控制 | 以消除发送方使接收方缓冲区溢出的可能性。 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配 TCP 通过让发送方维护一个称为接收窗口（receive window）的变量来提供流量控制 是接收窗口（rwnd），它用于给发送方一个指示：接收方还能接收多少数据， 接收方会将此窗口值放在 TCP 报文的首部中的窗口字段，然后传递给发送方，这个窗口的大小是在发送数据的时候动态调整的。 |
| 差错控制 | TCP 协议也会采用校验和的方式来检验数据的有效性 |
| 拥塞控制 | 情况： 如果一个主机还是以很大的流量给另一个主机发送数据，但是其中间的路由器通道很小，无法承受这样大的数据流量的时候，就会导致拥塞的发生，这样子就导致了接收方无法在超时时间内完成接收（接收方此时完全有能力处理大量数据），而发送方又进行重传，这样子就导致了链路上的更加拥塞，延迟发送方必须实现一直自适应的机制。 延迟发送方必须实现一直自适应的机制，在网络中拥塞的情况下调整自身的发送速度， |
端口号
传输层与上层协议是通过端口号进行识别的
端口号取值范围： 0~65535
| 一台拥有 IP 地址的主机可以提供许多服务，比如 Web 服务、FTP 服务、SMTP 服务等，这些服务完全可以通过 1 个 IP 地址来实现，主机是怎样区分不同的网络服务呢？ 显然不能只靠 IP地址，因为 IP 地址只能识别一台主机而非主机提供的服务，这些服务就是主机上的应用线程，因此是通过“IP 地址+端口号”来区分主机不同的线程。 |
|---|
TCP 报文段结构
| TCP首部片段 | 长度 /bit |
解释 |
|---|---|---|
| 序号字段 | 32 | 用来标识从 TCP 发送端向 TCP 接收端发送的数据字节流， 它的值表示在这个报文段中的第一个数据字节所处位置吗， 根据接收到的数据区域长度 ，就能计算出报文最后一个数据所处的序号，因为 TCP 协议会对发送或者接收的数据进行编号。 |
| 首部长度 | 4 | 它指出了 TCP 报文段首部长度，以字节为单位，最大能记录 15*4=60 字节的首部长度。 |
| URG | 1 | 首部中的紧急指针字段标志，如果是 1 表示紧急指针字段有效。 |
| ACK | 1 | 首部中的确认序号字段标志，如果是 1 表示确认序号字段有效。 |
| PSH | 1 | 该字段置一表示接收方应该尽快将这个报文段交给应用层。 |
| RST | 1 | 重新建立 TCP 连接。 |
| SYN | 1 | 用同步序号发起连接。 |
| FIN | 1 | 中止连接。 |
| 窗口大小 | 16 | 窗口大小为字节数 起始于确认序号字段指明的值，这个值是接收端正期望接收的数据序号，发送方根据窗口大小调整发送数据，以实现流量控制。 窗口最大为 65535 字节，当接收方告诉发送方一个大小为 0 的窗口时，将完全阻止发送方的数据发送。 |
三次握手 四次挥手
三次握手建立连接
| 第一次握手 （SYN） |
客户端向服务器发送一段报文 SYN 标志位会被置为 1 这个特殊报文段被称为 SYN 报文段（握手请求报文） 填充序号段 设置一个初始序号（ISN，假设为 A）填充到序号字段。 ACK 标志位 0 它的确认序号段是无效的。 |
|---|---|
| 第二次握手 （SYN ACK segment） |
服务器向客户端发送一段报文 握手应答报文 【服务器分配TCP缓存和变量】【告知客户端的窗口大小】 SYN 与 ACK 标志都被置为 1 填充序号段 设置为 A+1（这个 A（ISN）是从握手请求报文中得到）。 服务器随机选择自己的初始序号 服务器随机选择自己的初始序号（ISN，注意此 ISN 是服务器端的 ISN，假设为B），并将其放置到 TCP 报文段首部的序号字段中。 |
| 第三次握手 | 客户端TCP 连接分配缓存和变量 【告知服务器的窗口大小】 可以在报文段数据区域中携带客户到服务器的数据 ACK 标志设置为 1 SYN 标志置为 0 因为连接已经建立了，所以该标志会被置为 0。 确认序号字段 设置为 B+1 |
:::info 在握手结束后，发送的每一段报文里 SYN 标志都会被置 0，因为它只用于发起连接，同步序号。 :::
四次挥手终止连接
| 第一次挥手 （FIN 报文段） |
客户端向服务器发送 FIN 标志位 置为1 ACK 标志 置一，但确认序号字段是无效的。 假设此时序号为C |
|---|---|
| 第二次挥手 （ASK 报文段） |
服务器发送报文ASK 序号为C+1 此时断开客户端->服务器的方向连接 |
| 第三次挥手 | 服务器会向应用程序请求关闭与这个客户端的连接 服务器向客户端发送 FIN 标志位 置为1 ACK 标志 置一，但确认序号字段是无效的。 假设序号为D |
| 第四次挥手 | 服务器发送报文ASK 序号为D+1 此时断开服务器->客户端的方向连接。 |
问题
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
【问题3】为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
若有收获，就点个赞吧
0 人点赞
