TCP三次握手 四次挥手/TCP拥塞控制/TCP流量控制/TCP与UDP的区别/

        TCP与UDP的区别
        TCP的三次握手和四次挥手
                [TCP三次握手 四次挥手](https://o-fawkes.blog.csdn.net/article/details/77413870)
        TCP流量控制
        TCP拥塞控制
            慢开始：乘法增加
            拥塞避免：加法增大
            快重传
            快恢复
 

    腾讯面试十分注重网络基础知识，问的几乎都是一些细节知识，所以你如果想进入腾讯的话，网络知识一定要扎实，文章是我总结的一些腾讯面试经常问到的一些细节知识，希望对你有帮助，觉得不错的，可以点赞收藏

TCP与UDP的区别

    TCP面向连接的, 传输数据时，需先进行三次握手,建立连接，UDP是无连接的，发送数据之前不需要建立连接
    TCP通过确认和重传机制，提供可靠的服务。即通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达，而UDP不保证可靠传输,只是尽可能得交付
    TCP面向字节流，即将数据看成一连串无结构的字节流。UDP是面向报文的,UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
    每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
    TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

TCP的三次握手和四次挥手

TCP是面向连接的字节流协议，是全双工的。
三次握手

例图：

        第一次握手：客户端发送一个连接请求,测试服务端是否可以正常通信(SYN位置为1)
        第二次握手：服务端确认客户端的连接请求，并且同时发送一个请求,测试客户端是否可以正常通信(SYN位置为1, ACK位置为1)
        第三次握手：客户端接受到服务端的确认(了解到服务器可以正常通信)，之后发送一个ACK,告诉服务器我可以正常通信(ACK位置为1)

如果服务器没有收到客服端的ACK，会超时重传自己的SYN请求，一直到收到服务端的ACK为止
为什么一定是三次握手呢？

考虑两次握手：客户端发送一个连接请求，服务端接受到连接请求，发送一个确认,此时服务端已经确认自己有接受报文的能力，认为连接已经建立，所以开始为已建立的连接分配资源，如果服务端发送的确认丢失，客户端就无从知道连接已经建立。如果存在大量这种情况，就有可能会造成服务器崩溃。

为什么不是四次呢？三次都已经够了，为什么还要多加一次
四次挥手

例图：

    第一次挥手：客户端的数据到达尾部，向服务端发送请求断开(FIN位置1)

    相当于我这边数据传送完了，准备断开连接了

    第二次挥手：TCP的连接是全双工的双向连接，关闭必须从两边关闭，服务端收到FIN标志位后，并不会立即向客服端发送FIN标志位，而是发送一个ACK的应答信息

    相当于：你请求关闭的请求我已经收到，但我可能还有数据没有接受完(数据传送需要时间)，你再等下，等我数据传输完成了我就告诉你

    第三次挥手：服务端接受数据完成，向服务端发送一个FIN=1

    第四次挥手：客户端接收到服务端发送来的断开连接请求，发送一个确认。并把自己设置成TIME_WAIT状态，并启动计时器

    如果服务端没有收到ACK, 服务端的TCP的定时器到达后，会要求客户端重新发送ACK, 服务端收到ACK就断开连接，当客户端等待2MSL(2倍报文最大生存时间)后，没有收到服务端的重传请求后，就知道服务端已经接收到ACK,此时关闭自己的连接
 

TCP流量控制

    很多人会将流量控制和拥塞控制搞混，所以单独拎出来，考究细节

流量控制：如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。流量控制策略就是控制发送者的发送速度，使得接收者来得及接收,达到不丢失分组的目的。流量控制是构成TCP可靠性的一方面。

流量控制主要使用滑动窗口机制实现。下面以上图讲解滑动窗口(也叫接受窗口rwnd)的细节

主机A向主机B发送数据，开始双方确定的窗口值为400字节,这两个是前提条件。开始A发送了200字节，之后发生了分组丢失现象，B调整接受窗口大小为300字节。之后A又连续发送了300字节。此时A已经不能发送数据，需等待B的窗口信号。之后B调整窗口为100字节。接收到100字节数据后，调整窗口值为0，表示暂时不想接受数据。总共B调整了三次窗口大小，进行了三次流量控制

假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
TCP拥塞控制

    拥塞控制，大家都能背出来，什么慢开始、拥塞避免、快重传、快恢复，大家都耳熟能详，但是有些细节问题，可以大家没有留意，比如快重传阶段后，为什么不直接进入慢开始阶段，而是进入拥塞避免阶段？

拥塞的概念：在某段时间，对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫拥塞。网络拥塞往往是由许多因素引起的，简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。拥塞问题的是指往往是整个系统的各个部分不匹配，只有各个部分平衡了，问题才会得到解决。

拥塞控制：防止过多的数据注入到网络，导致网络中的路由器或链路过载。

流量控制和拥塞控制的区别：可以看出流量控制是一个端到端的问题，而拥塞控制是一个全局性问题，设计到所有的主机、所有的路由器。

慢开始：乘法增加

发送方维持一个拥塞窗口cwnd，大小取决于网络的拥塞程度，动态地在变化。发送窗口小于等于拥塞窗口，而发送窗口一定不能超过接收窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去。但是只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络的分组数。

开始时，如果发送大量数据包，容易导致网络中路由器缓冲空间耗尽，从而发生拥塞。所以新建连接时，cwnd初始化为1个最大报文段(MSS)大小，

对于IPv4，为了避免IP分片，主机一般默认MSS为536字节 （576IP最大字节数-20字节TCP协议头-20字节IP协议头=536字节）。同理，IPv6的主机默认MSS为1220字节（1280IP最大字节数-20字节TCP协议头-40字节IP协议头=1220字节）。 [1]  当发送方主机想要调整MSS时，应注意以下几点：

1. MSS不包含TCP及IP的协议头长度。 [1] 

2. MSS选项只能在初始化连接请求（SYN=1）使用。 [1] 

3. 发送方与接收方的MSS不一定相等

每经过一个迭代，拥塞窗口就乘以2，所以也称为乘法增加阶段。拥塞窗口不可能一直增大，所以一般会设置一个慢开始门限ssthresh.

    当cwnd<ssthresh时，使用慢开始算法。
    当cwnd>ssthresh时，改用拥塞避免算法。

拥塞避免：加法增大

一旦达到慢开始的初始门限ssthresh,就进入了拥塞避免阶段。每一个迭代，拥塞窗口加1，而不是加一倍
快重传

快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。快重传策略是为了防止TCP连接因等待重传计时器超时而空闲较长的时间。

快恢复

快重传和快恢复是搭配使用的，快重传完成后，立即执行快恢复算法。将ssthresh门限设置为当前拥塞窗口的一般，之后将拥塞窗口设置为新的ssthresh门限(即减半), 进入拥塞避免阶段。

这里可能会有人有疑问，为什么不直接进入慢开始阶段，更彻底得避免拥塞。主要的原因是考虑到如果网络出现拥塞得话，就不会收到多次重复确认，所以发送方认为网络可能没有出现拥塞，所以不执行慢开始算法，而是将cwnd设置为新得ssthresh门限，执行拥塞避免算法
————————————————
版权声明：本文为CSDN博主「zycxnanwang」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zycxnanwang/article/details/105911876