【计算机网络】传输层·TCP详解
传输层
TCP和UDP区别/优缺点/应用
| 用户数据报协议 UDP（User Datagram Protocol） | 传输控制协议 TCP（Transmission Control Protocol） |
|---|---|
| 无连接 | 面向连接 |
| 使用尽最大努力交付 | 提供可靠交付 |
| 没有拥塞控制 | 有流量控制，拥塞控制 |
| 面向报文 | 面向字节流 |
| 8个字节信息包 | 20个字节信息包 |
| 可能丢包 | 保证数据正确性和顺序 |
| 支持一对一、一对多、多对一和多对多的交互通信 | TCP 连接只能是点对点的（一对一） |
| 在数据传输方面速度更快，延迟更低，实时性更好，应用于数据量大且精确性要求不高的数据传输（通信领域和视频网站） | 主要应用于文件传输精确性相对要求较高且不是很紧急的情景，比如电子邮件、远程登录等 |
| – | – |
TCP状态转移解释和首部格式解释详见↓↓↓
https://blog.csdn.net/qq_38646470
TCP三次握手及原因
☆为什么不是两次或者四次握手？☆
为什么不能两次？
如果第二次不发送SYN+ACK，只是发送确认应答消息ACK，会造成只能建立单向通信，而且不能应答。而TCP是全双工通信的，而且必须保证可靠性。
如果第二发送SYN+ACK，不用应答。此时会出现三种情况
- 二次握手失败，C端会重复发送SYN报文，等待对端发送确认报文，S端会保存tcp连接的所有资源，大量的这种情况会导致S资源耗尽。
- 二次握手成功，S收不到ACK会重复发送SYN+ACK报文。
- 二次握手完以后，双方以为连接建立成功，即可开始通信。假如此时连接并没有真的建立成功，S端开始发送消息，会造成网络拥堵发生。
为什么不能是四次？
四次其实原则上来说是可以的，就是把第二次的ACK和SYN分两次发送。在理论上是完全可以行得通的，但是TCP本着节约网络网络资源的前提。
还有一种是不拆开二次握手的捎带应答，三次握手之后C端继续发送SYN报文，其时这是徒劳的。第三次完成以后链接已经建立，后面无论多少次都是徒劳。
如果双方同时建立连接，会发生什么情况？
这就是双方同时建立链接的情况，情况还不错，反正能建立成功，这点是肯定的。但是要注意两点
- 此时只会建立一条全双工的TCP链接，不是两条。
- 双方没有CS之分，两端都是同时承担两个角色，客户端和服务器。
为什么不能用三次握手中捎带应答机制减少一次握手？
这点到是很迷惑人，但是掌握了TCP传输的一些细节就会发现并不难。
TCP是全双工通信的，S收到断开链接请求后只是表示C端不会传输数据到S端了，但是并不表示S端不传输数据到C端。
如果采用捎带应答，S端将无法把剩余的数据传输到C端。
☆TCP三次握手，如果server出现问题，client会怎么做？（每次握手，报文丢失会怎样？）☆
采用C/S模式解释，假设C端发起传输请求。
在发送建立链接请求之前，C端是保持CLOSED状态，S端最开始也是处于CLOSED状态，当执行listen函数套接字进入被动监听状态。
所谓被动监听，是指当没有客户端请求时，套接字处于“睡眠”状态，只有当接收到客户端请求时，套接字才会被“唤醒”来响应请求。
第一次：C端发送SYN=1的请求报文，此时C端进入SYN SENT状态，等待服务器确认。
- 此时如果报文丢失发送不到对端会如何？
- C端发送报文之后会启动一个定时器，在超时之后未收到S端的确认，会再次发送SYN请求，每次尝试的时间会是第一次的二倍，如果总的总尝试时间为75秒，此次建立链接失败。
第二次： S端收到C端发送的SYN报文(建立链接请求)后，S端必须返回确认号并且同时发送一条SYN报文，此时进入SYN RCVD状态。
- 为啥要连带发送SYN报文？
- TCP是全双工通信，协议规定当收到建立链接请求后必须返回***，同时建立本端到对端的通信链接。这也叫做捎带应答机制。
- 如果第二次报文丢失怎么办？
- 在发送完ACK+SYN报文后会启动一个定时器，超时没有收到ACK确认，会再次发送，会进行多次重试。超时时间依旧每次翻倍，重试次数可设置。
修改/proc/sys/net/ipv4/tcp_synack_retries的值
第三次： C端收到S端发的ACK+SYN报文，需要返回一个应答ACK的报文，此时该连接会进入半连接状态的队列，当S端收到ACK后，一条完整的全双工TCP链接建立完成，双方进入ESTABLISHED状态。
- 这里有个常用攻击手段，攻击者伪造一个SYN请求发送给服务端，服务端响应之后，会收不到C端的ACK确认，服务端会不断的重试，默认会重试五次。
此时服务端会维持这个链接的所有资源，如果有大量这样的请求，服务端的资源会被耗完。
这就是DOS攻击。- 如果第三次报文丢失怎么办？
- S端在发出ACK+SYN报文后会启动一个定时器，在超时触发还没收到ACK就确认是丢失了，会重试一次发送。
TCP四次挥手及原因
☆为何最后一次ACK之后需要等待2MSL的时间？ TIME_WAIT状态☆
网络是不可靠的，TCP是可靠协议，必须保证最后一次报文送达之后才能断开链接，否则会再次收到S端的FIN报文信息。
而等待2MSL时间就是为了保证最后最后一次报文丢失时还能重新发送。
为何是2MSL的时间？
2MSL是报文一个往返的最长时间，假设小于这个时间会发生，ACK丢了，但是还没接收到对方重传的FIN我方就重新发送了ACK。
☆如果已经建立了连接，但是客户端突然出现故障了怎么办？☆
这个不难TCP自己做了保证，TCP默认有个定时器，每次收到客户端的请求后会把定时器设置好，通常设置两小时，超过两小时还没收到数据，服务端会发送一个探测报文，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
TCP传输机制
超时重传机制
TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT。详见。RTT解释。
超时时间 RTO 应该略大于 RTTs。
TCP滑动窗口
窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31}按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。
TCP流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。
TCP拥塞控制
如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。
发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
为了便于讨论，做如下假设：
- 接收方有足够大的接收缓存，因此不会发生流量控制；
- 虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。
慢开始与拥塞避免
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
快重传与快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。
在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd =ssthresh，注意到此时直接进入拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd设定为 ssthresh。
拥塞控制看这里！！！！