TCP
TCP 保证可靠性
序列号,确定应答
超时重传
窗口控制和高速重发控制/快速重传 (重复确定应答)
拥塞控制
-
序列号,确定应答,超时重传
数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明了它下一次需要接收的数据序列号。如果发送发迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。这个时间一般是2*RTT(报文段往返时间）+一个偏差值。
-
窗口控制与高速重发控制/快速重传（重复确认应答）
TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制，每一个没收到确认应答的数据都要重发。
使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接收1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发；但还有种情况有可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会放过它的，会疯狂向它提醒…
-
拥塞控制
如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以TCP在为了防止这种情况而进行了拥塞控制。
拥塞机制是怎么调控的?
慢启动：定义拥塞窗口，一开始将该窗口大小设为1，之后每次收到确认应答（经过一个rtt），将拥塞窗口大小*2。
拥塞避免：
设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加（每次确认应答/每个rtt，拥塞窗口大小+1），以此来避免拥塞。
将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗口大小设为初值1，然后重新进入慢启动过程。
快速重传：在遇到3次重复确认应答（高速重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。
然后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3的大小。
这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的过程，网络不会轻易的发生瘫痪。
采用慢开始和拥塞避免算法的时候
- 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度
- 一旦出现丢包的情况，就重新进行慢开始，减慢增长速度
采用快恢复和快重传算法的时候
- 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度
- 一旦发送方连续收到了三个重复确认，就采用拥塞避免算法，减慢增长速度
三次握手和四次挥手
TCP建立连接和断开连接的过程：
SYN(synchronous建立连接)
ACK(acknowledgement 表示响应、确认)
PSH(push表示有DATA数据传输)
FIN(finish关闭连接)
RST(reset表示连接重置)
URG(urgent紧急指针字段值有效)
三次握手
-
Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
-
Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
-
Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server
Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
**确认号：其数值等于发送方的发送序号+1(即接收方期望接收的下一个序列号)。**
四次挥手
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
-
数据传输结束后，客户端的应用进程发出连接释放报文段，并停止发送数据，客户端进入FIN_WAIT_1状态，此时客户端依然可以接收服务器发送来的数据。
-
服务器接收到FIN后，发送一个ACK给客户端，确认序号为收到的序号+1，服务器进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。
-
当服务器没有数据要发送时，服务器发送一个FIN报文，此时服务器进入LAST_ACK状态，等待客户端的确认
-
客户端收到服务器的FIN报文后，给服务器发送一个ACK报文，确认序列号为收到的序号+1。此时客户端进入TIME_WAIT状态，等待2MSL（MSL：报文段最大生存时间），然后关闭连接。
TCP的四次挥手过程（简言之）：主动关闭方向被动关闭方发送不会再给你发数据了的信息；被动关闭方对收到的主动关闭方的报文段进行确认；被动关闭方向主动关闭方发送我也不会再给你发数据了的信息；主动关闭方再次对被动关闭方的确认进行确认。
为什么会采用三次握手，若采用二次握手可以吗？
答：建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况，因此采用三次握手刚刚好，两次可能出现失效，四次甚至更多次则没必要，反而复杂了。
流量控制(滑动窗口)拥塞控制的工作流程
流量控制
-
什么是流量控制
Sender won’t overflow receiver’s buffer by transmitting too much, too fast.
（防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理）
-
流量控制的一些知识点
（1）接收端抑制发送端的依据：接收端缓冲区的大小
（2）流量控制的目标是接收端，是怕接收端来不及处理
（3）流量控制的机制是丢包 -
怎么样实现流量控制呢?
使用滑动窗口
滑动窗口
-
滑动窗口是什么?
滑动窗口是类似于一个窗口一样的东西，是用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小，这样就可以实现
ps：窗口指的是一次批量的发送多少数据 -
为什么会出现滑动窗口?
在确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是
性能比较差，尤其是数据往返的时间长的时候使用滑动窗口，就可以一次发送多条数据，从而就提高了性能
-
滑动窗口的一些知识点
（1）接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK来通知发送端
（2）窗口大小字段越大，说明网络的吞吐率越高
（3）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据
（4）操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉?
ps：发送缓冲区如果太大，就会有空间开销（5）接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端收到这个值后，就会减慢自己的发送速度
（6）如果接收端发现自己的缓冲区满了，就会将窗口的大小设置为0，此时发送端将不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端
ps：在TCP的首部中，有一个16位窗口字段，此字段就是用来存放窗口大小信息的
-
滑动窗口的优点
可以高效可靠的发送大量的数据
拥塞控制
-
什么是拥塞控制
too many sources sending too much data too fast for network to handle
防止发送方发的太快，使得网络来不及处理，从而导致网络拥塞 -
拥塞控制使用的机制：AIMD\slow start
slow start: 慢启动
A: additive（加法的）
I: increase（增加）
M: multiplicative（乘法的）
D: decrease（减少）
即就是加法增加，乘法减少---->加增乘减-
加法增加
是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口cwnd增加一个MSS大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞
-
乘法减少
出现一次超时（即出现一次网络拥塞），就把慢开始门限值ssthresh设置为当前的拥塞窗口值乘以0.5
ps：当网络频繁出现拥塞时，ssthresh值就下降的很快，以大大减少注入到网络中的分组数
-
-
发送方如何知道已经丢包?
-
为什么会有拥塞控制
流量控制虽然可以高效可靠的传送大量的数据，但是如果在刚开始阶段就发送大量的数据，可能会导致网络拥堵，因为网络上的计算机太多了
-
拥塞控制的表现
- 丢包
- 延时边长
-
拥塞控制的工作过程
初始化阶段: 设置拥塞窗口cwnd为1
慢开始阶段:拥塞窗口cwnd指数增长
? (1) 在执行慢开始算法时,拥塞窗口cwnd的初始值为1,发送第一个报文段M0
? (2) 发送端每收到一个确认,就把cwnd加1,于是发送端就可以接着发送M1,M2两个报文端
? (3) 接收端共发回两个确认,发送端每收到一个对新报文段的确认,就把发送端的cwnd加1,现在cwnd从2增大到4,并可接着发送后面的4个报文段
? (4) 发送端每收到一个对新报文段的确认，就把发送端的拥塞窗口加1，因此拥塞窗口cwnd随着传输轮次按指数规律增长。
拥塞避免阶段 :拥塞窗口按线性规律增长
当拥塞窗口cwnd增长到慢开始门限值ssthresh时，就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
拥塞调整阶段: 拥塞窗口ssthresh减小为1/2
? (1) 假定拥塞窗口的数值增长到24时，网络出现超时，表明网络拥塞了。
? (2) 更新后的ssthresh值变为12（即发送窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。? (3) 当cwnd = 12时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个MSS的大小。
流量控制和拥塞控制的区别
-
相同点
（1）现象都是丢包；
（2）实现机制都是让发送方发的慢一点，发的少一点 -
不同点
（1）丢包位置不同
流量控制丢包位置是在接收端上
拥塞控制丢包位置是在路由器上
（2）作用的对象不同
流量控制的对象是接收方，怕发送方发的太快，使得接收方来不及处理
拥塞控制的对象是网络，怕发送发发的太快，造成网络拥塞，使得网络来不及处理 -
联系
- 拥塞控制
拥塞控制通常表示的是一个全局性的过程，它会涉及到网络中所有的主机、
所有的路由器和降低网络传输性能的所有因素 - 流量控制
流量控制发生在发送端和接收端之间，只是点到点之间的控制
- 拥塞控制
TCP和UDP的差异,分别有什么应用场景
概述
两者都是通信协议， TCP、UDP 是传输层协议，但他们的通信机制与应用场景不同，下面来阐述两者的区别以及它们的应用场景。
TCP（Transmission Control Protocol），又叫传输控制协议，UDP（User Datagram Protocol），又叫用户数据报协议，它们都是传输层的协议，但两者的机制不同，它们的区别如下：
TCP
从如上表格看到，TCP 是面向连接的，并且是一种可靠的协议，在基于 TCP 进行通信时，通信双方需要先建立一个 TCP 连接，建立连接需要经过三次握手，握手成功才可以进行通信， 另外 TCP 协议是一种可靠的传输协议，那么它是如何保证可靠性的呢？
可靠性
在了解 TCP 如何保证可靠性前，首先得理解什么是可靠。在通信的角度来看，可靠即要确保通信双方的通信信息不会丢失，若丢失了保证能够对其进行恢复，并且收到的信息内容与原发送内容一样。
- 在 TCP 中，传输报文都是通过建立的虚拟连接来进行传输，发送端传输的每一个 TCP 报文，都会对其进行编号（编号是由于网络传输的原因，发送的报文可能会乱序到达，因此需要根据编号对报文进行重排），并且开启一个计时器；当接收端收到报文后，并且通过校验和对收到的报文数据进行校验，若校验成功则会返回一个确认报文，告知发送端我已经成功收到该报文了；若发送端在计时器结束前仍未收到确认报文，则认为接收端接收失败，则会重传该报文；服务端若收到重复报文（根据编号发现已经是收到了），则会将该报文丢弃。
- 因此，从上面的机制可以知道，TCP 是通过重传、确认和校验和的方式来确保可靠。
注：校验和并不能检验数据是否被篡改过，想要保证数据的完整性可以了解一下数字签名
UDP
UDP 是一种面向无连接，且不可靠的协议，在通信过程中，它并不像 TCP 那样需要先建立一个连接，只要（目的地址，端口号，源地址，端口号）确定了，就可以直接发送信息报文，并且不需要确保服务端一定能收到或收到完整的数据。它仅仅提供了校验和机制来保障一个报文是否完整，若校验失败，则直接丢弃报文，不做任何处理。
TCP 与 UDP 的应用场景
-
TCP 是可靠的但传输速度慢 ，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定。
-
若通信数据完整性需让位与通信实时性，则应该选用 TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。
三次握手和四次挥手
三次握手
第一次握手：客户端向服务端发送SYN包，等待服务端响应，并进入SYN-SEND状态
第二次握手：服务端收到SYN包，并确定SYN=ACK+1,然后响应一个SYN包和ACK包。客户端进入SYN-RECV状态。
第三次握手：客户端收到服务端SYN+ACK包。向服务器发送确认包ACK。发送完毕进入ESTABLISHED状态。>
四次挥手
第一次挥手：主动关闭连接一方，发送FIN包。此时发送FIN包之前发送的数据如果没有发送到。会进行重试发送。
第二次挥手：被动关闭一方收到FIN包。响应一个ACK包。
第三次挥手：被动关闭方发送一个FIN包。告诉被动关闭方。数据发送完毕。
第四次挥手：主动关闭方收到FIN包。发送一个ACK包给被动关闭方，至此四次挥手结束，断开连接。
https://blog.csdn.net/buknow/article/details/81157002