计算机网络通关整理2-TCP、UDP、三次握手、四次挥手、流量控制、拥塞控制、粘包
网上收集整理，仅供笔记参考学习
计算机网络通关整理1-OSI、TCP/IP、Socket、IP地址
计算机网络通关整理2-TCP、UDP、 三次握手、四次挥手、流量控制、拥塞控制、粘包
计算机网络通关整理3-HTTP、状态码、Cookie、Session、HTTPS、Socket
TCP：传输控制协议
UDP：用户数据报协议
TCP和UDP对比
- 基于连接 vs 无连接
TCP 是面向连接的协议，而 UDP 是无连接的协议。这意味着当一个客户端和一个服 务器通过 TCP 发送数据之前，必须先建立连接，建立连接的过程也被称为 TCP 三次握手。 - 可靠性
TCP 提供交付保证,这意味着一个使用 TCP 协议发送的消息是保证交付给客户端的， 如果消息在传输过程中丢失,那么它将重发。UDP 是不可靠的,它不提供任何交付的保证， 一个数据报包在运输途中可能会丢失。 - 有序性
消息到达网络的另一端时可能是无序的，TCP 协议将会为你排好序。UDP 不提供任何 有序性的保证。 - 速度
TCP 速度比较慢，而 UDP 速度比较快，因为 TCP 必须创建连接，以保证消息的可靠 交付和有序性，他需要做比 UDP 多的事。这就是为什么 UDP 更适用于对速度比较敏感的 应用。TCP 适合传输大量数据，UDP 适合传输少量数据。 - 重量级 vs 轻量级
TCP 是重量级的协议，UDP 协议则是轻量级的协议。 - 流量控制或拥塞控制
TCP有流量控制和拥塞控制。UDP 没有流量控制和拥塞控制。 - TCP 面向字节流，UDP 是面向报文的。
TCP 是字节流的协议，无记录边界。 UDP 发送的每个数据报是记录型的数据报，所谓的记录型数据报就是接收进程可以识 别接收到的数据报的记录边界。 - TCP 只能单播，不能发送广播和组播；UDP 可以广播和组播。
TCP和UDP应用场景
TCP 应用场景：
效率要求相对低，但对准确性要求相对高的场景。因为传输中需要 对数据确认、重发、排序等操作，相比之下效率没有 UDP 高。举几个例子：文件传输、邮件传输、远程登录。
UDP 应用场景：
效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ 聊天、QQ 视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问 题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。
UDP 为何快？
1.不需要建立连接
2.对于收到的数据，不用给出确认
3.没有超时重发机制
4.没有流量控制和拥塞控
TCP
TCP 头部有哪些字段
报文比较重要的字段有：
Seq序号：用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
Ack序号：只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。
ACK：确认序号有效。
SYN：发起一个新连接。
FIN: 表示关闭连接。
TCP的三次握手
TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接
A: 报文发起
当客户端想要对服务器联机时，客户端随机取用一个大于1024以上的端口向服务器发送一个报文，在此报文中，CODE字段中的SYN位要标记为1，并且生成一个随机的序号Sequence number，假设此时该值为10001。
报头信息： SYN=1 seq=10001
B: 报文接收与确认报文传送
当服务器接收到这个报文，并且确定要接收这个报文后，会向客户端发送一个报文，该报文做了如下两件事：
告知客户端已经收到您的信息
将CODE字段中的ACK置为1，并且将接收到的Sequence number加一赋值给响应报文的Acknowledge number字段(ack = 10001+1 = 10002)
确认客户端可以接收服务器发送的报文
将CODE字段中的SYN置为1，并且生成一个随机的Sequence number，假设此时只为20001。(跟步骤A一样的操作)
报头信息： ACK=1 ack=10002 SYN=1 seq=20001
C: 回送确认报文
当客户端收到来自服务端的ack后，就能够确认A步骤的报文被正确的接收。此时我们还要回应服务端我们是否接收到了他的请求，所以还要在发送一个确认报文，流程跟B步骤中的第一步一致
报头信息： ACK=1 ack=20002
带有SYN标志的过程是不可以携带数据的，也就是说三次握手的前两次是不可以携带数据的(逻辑上看，连接还没建立，携带数据好像也有点说不过去)，但建立连接的第三次握手允许携带数据。
D: 取得最后确认
若一切都顺利，在服务器端收到带有 ACK=1 且 ack=20002 序号的封包后，就能够建立起这次的联机了。
为什么是三次挥手，不是两次，也不是四次
TCP作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输的效率
如果两次，那么B无法确定B的信息A是否能收到，所以如果B先说话，可能后面的A都收不到，会出现问题 。
如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。
TCP的四次挥手
FIN: 表示关闭连接
1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
3）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
4）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。
为什么A在TIME-WAIT状态必须等待2MSL的时间？
MSL最长报文段寿命Maximum Segment Lifetime，MSL=2
两个理由：
1.确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
2.等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。
这个ACK报文段有可能丢失，B收不到对已发送的FIN+ACK报文段的确认，
为什么连接的时候是三次握手，关闭的时候却是四次握手？
连接时：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
关闭时：当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
TCP流量控制（滑动窗口）
我们从一台机器向另外一台机器发送数据的时候，数据并不是一口气也不可能一口气传输给接收方。这个并不难理解，因为网络环境特别的复杂，有些地方快有些地方慢
所以，操作系统把这些数据写成连续的数据包，并且以一定的速率发给对方。
操作系统将这些数据包一批一批的发送给对方，就像一个窗口，不停地往后移动，所以，我们称之为TCP滑动窗口协议。
TCP的滑动窗口协议有什么意义呢？
1.首先当然是可靠性，滑动窗口只有在队列前部的被确认之后，才会往后移动，保证数据包被接收方确认并接收。
2.其次是传输效率，假如没有窗口，服务端是杂乱无章地进行发包，因为TCP的队首效应，如果有前面的包没有发送成功，就会不停的重试，反而造成更差的传输效率。
3.最后是稳定性，TCP的滑动窗口大小，是整个复杂网络商榷的结果，会进行动态调整，可以尽量地避免网络拥塞，更加稳定。
TCP拥塞控制
在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞。
我们每个人都在高速上网时，可能因为并发量太大，数据太多，导致链路压力太大，最后大家网速都不咋地，类似于过节开车上高速堵住一样。
拥塞控制就是防止这种现象的发生，或者缓解拥堵问题。
拥塞控制方法： 慢开始和拥塞避免、快重传和快恢复。
慢开始：发送方先探测一下网络的拥塞程度，并不是一开始就发送大量的数据，然后根据拥塞程度慢慢的增大或减小拥塞窗口
拥塞避免：该算法用来控制拥塞窗口的增长速率，每一次 RTT 往返之后，拥塞窗口 + 1 而不是翻倍，这样的话拥塞窗口以线性速率增长，流量可控。
快重传：当发送方没有在超时期限内收到确认信号的话就认为网络阻塞了，此时拥塞窗口变为 1 ，同时把慢开始门限值 ssthresh 减半。
一旦接收方连续 3 次收到同一个重复确认就会立马启动快重传算法，即立马重传 M3
快恢复：快恢复是配合快重传使用的。 M3 丢失，可能是因为 M3 在某个节点因为网络波动等非网络拥挤情况阻塞住了。
也就是网络其实并没有拥塞，快恢复就是在此情况下避免直接重传会真正导致网络阻塞，其原理就是先将拥塞窗口设置成 ssthresh 的大小，然后执行拥塞避免算法
TCP 如何实现流量控制和拥塞控制。tcp 是怎么做错误处理的？
1）流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。
原理这就是运用 TCP 报文段中 的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。
2）四种拥塞控制方法： 慢开始和拥塞避免、快重传和快恢复。
TCP的粘包
TCP 报文粘连就是，本来发送的是多个 TCP 报文，但是在接收端收到的却是一个报文， 把多个报文合成了一个报文。
报文粘连的原因： "粘包"可发生在发送端，也可发生在接收端。在流传输中出现，UDP 不会出现粘包，因为它有消息边界（两段数据间是有界限的）。
1.由 Nagle 算法造成的发送端的粘包
Nagle 算法产生的背景是，为了解决发送多个非常小的数据包时（比如 1 字节），由 于包头的存在而造成巨大的网络开销。简单的讲，Nagle 算法就是当有数据要发送时，先 不立即发送，而是稍微等一小会，看看在这一小段时间内，还有没有其他需要发送的消息。
当等过这一小会以后，再把要发送的数据一次性都发出去。这样就可以有效的减少包头的
发送次数。
2.接收端接收不及时造成的接收端粘包
TCP 会把接收到的数据存在自己的缓冲区中,然后通知应用层取数据.当应用层由于某 些原因不能及时的把 TCP 的数据取出来,就会造成 TCP 缓冲区中存放了几段数据，产生报 文粘连的现象。
TCP 报文粘连的解决方法：
1.关闭 Nagle 算法。在 scoket 选项中，TCP_NODELAY表示是否使用 Nagle 算法。
2.接收端尽可能快速的从缓冲区读数据。
3.可以在发送的数据中，添加一个表示数据的开头和结尾的字符，在收到消息后，通过这 些字符来处理报文粘连。