传输层-TCP,UDP协议小小总结

TCP、UDP协议

1.TCP和UDP

1.1传输层的TCP和UDP对比

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多	只能一对一
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	最小20字节，最大60字节(4bit表是首部长度，2^4-1=15*4=60)
场景	适用于实时应用（ip电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

2.TCP协议

2.1TCP报文段结构

2.2三次握手

• 
• 为什么TCP连接的时候是3次？2次不可以吗？
  • 因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。
• 如果已经建立了连接，但是客户端突然出现故障了怎么办？
  • TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

2.3四次挥手

• 
• 为什么TCP连接的时候是3次，关闭的时候却是4次？
  • 因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。
• 为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？
  • 这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

2.4拥塞控制（慢开始、拥塞避免、快重传、快恢复）

• 发送方维持一个拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。
• 发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减少一些，以减少注入到网络中的分组数。
• 当连接开始，以指数增加速率，直到第一个丢失事件发生，cwnd=1。
• 慢启动门限ssthresh。
• 当cwnd < ssthresh时，使用慢启动算法；
  当cwnd > ssthresh时，停止使用慢启动算法而改用拥塞避免算法；
  当cwnd = ssthresh时，即可使用慢启动算法，也可以使用拥塞避免算法；
• 发生丢失事件时，ssthresh设置为发生丢失以前的cwnd的一半，并且cwnd设为1。
• 快重传算法规定，发送方只要一连收到**三个重复确认（即四个确认）**就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快恢复：考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的值，然后执行拥塞避免算法，使cwnd缓慢增大。

2.5流量控制（滑动窗口机制）

• 考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的话，那么发送方的发送窗口就一直为零导致死锁。
• 解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

3.UDP协议

3.1UDP报文段格式

• 
• 检查和：将段内容处理为16bit整数序列，进行加法（反码和，求和时溢出都被回卷）。接收方核对全部字段之和是否为全1。
• UDP并不提供流量控制，这可能导致缓存溢出。

法（反码和，求和时溢出都被回卷）。接收方核对全部字段之和是否为全1。

• UDP并不提供流量控制，这可能导致缓存溢出。

------本篇完------