UDP

UDP数据报

UDP的数据报分成数据报首部和数据两部分,其中数据就是应用层传输下来的数据.首部有4个部分组成,共占8个字节.分别是:16位源端口号,16位目的端口号,16位UDP报文长度,16位校验和.其中UDP报文长度规定了一个UDP数据报的可以传输的数据的范围为0-65535.校验和能够检验数据在传输过程中是否发生了损坏. 在这里插入图片描述

UDP的特点

无连接:使用UDP进行网络通信时只需要知道目的IP和目的端口号即可,无须和对方建立连接.
不可靠:没有安全机制,无法确认对方是否接收到了数据.即使因为网络故障导致对方没有正常接收到也不会反馈错误信息.
面向数据报:以数据报的形式发送数据.UDP没有真正意义上的发送缓冲区,发送的数据会直接通过内核传给网络层,UDP具有接收缓冲区,但接收缓冲区不能保证接收到的UDP数据报的顺序和发送顺序是一致的.
全双工:既能读也能写,也就是说客户端和服务器均可以作为发送方和接收方.
大小受限:UDP协议首部中的UDP报文长度规定了一个UDP能够传输的数据的最大长度是64k.比如当用QQ发送一段较长的文本时,有时候会自动转成文件发送.这就是因为发送的数据长度超过了UDP协议规定的报文长度.

基于UDP的应用层协议

NFS:网络文件系统
TFTP:简单文件传输协议
DHCP:动态主机配置协议
BOOTP:启动协议
DNS:域名解析协议

TCP

TCP协议段

TCP的协议段由TCP首部和数据两部分构成,其中数据即为应用层传输下来的数据.TCP首部有16位源端口号,16位目的端口号,32位序号,32位确认序号,4位首部长度,6位标志位,16位窗口大小,16位校验和,16位紧急指针,选项组成.

32位序号/32位确认序号:确认应答机制中用以区分数据先后的一种标识.
4位首部长度:表示TCP头部有多少个字节(4*15=60)
6位标志位
1. URG:紧急指针是否有效
2. ACK:确认号是否有效
3. PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
4. RST:对方要求重新建立连接,携带RST标识的也被称为复位报文段
5. SYN:请求建立连接, 携带SYN标识的也被称为同步报文段
6. FIN:通知对方,本端要关闭了,携带FIN标识的也被称为结束报文段
16位窗口大小:接收端接收缓冲区的剩余大小.
16位校验和:发送端填充CRC检验,接收端将检验结果反馈给发送端.
16位紧急指针:标识哪部分数据是紧急数据(比如视频,图片等及时性高的数据)
40字节头部选项

TCP原理

TCP对数据提供的管控机制:主要体现在安全和效率两方面.

确认应答机制(安全机制):保证可靠传输的核心机制.可靠性指的是发送方在发送数据之后能够得到接收方的反馈并能够确认接收方是否正常接收到了数据.当发送方发送数据给接收方后,接收方会向发送方发送一个ACK(acknowledge)告知发送方自己已经收到信息.我们知道数据在传输过程中是分组传输的.分组传输能够提高数据传输的效率,但因此也会造成一些麻烦:当发送方连续发送两次数据给接收方时,正常情况下接收方应该返回给发送方两个ACK,但网路传输过程中是充满不确定性的,经常会出现后发送的消息被接收方提前接收到.这也就造成了发送方无法区分接收方返回的ACK具体是哪一次发送的ACK.
针对上述问题引入序号和确认序号的概念.我们给发送方发送的数据进行标号,比如第一次发送的数据标号为1-1000(这里的1-1000指的是TCP报文首部中的序号为1,报文长度为1000),当接收方接收到之后会反馈一个1001的确认序号给发送方,此时发送方就可以分辨出这个ACK表示第一次发送的数据接收方正常接收到了.
至此,我们解决了接收方正常接收到信息的情况.但我们知道在某些情况下,接收方有可能无法正常接收到信息,因此引出超时重传机制.
超时重传机制(安全机制):发送方发送数据给接收方,接收方没有正常收到.进而导致发送方无法得到接收方反馈的ACK.这时发送方会在等待一段时间之后重新发送这一部分数据给接收方;当然也存在接收方接收到了信息,在反馈ACK时因为网络变差导致发送方没有接收到ACK.在这种情况下发送方也会在等待一段时间之后重新向接收方发送数据.这样就会导致接收方收到很多重复的数据,TCP内部会将接收到的数据放到操作系统内核的"接收缓冲区"中,通过数据发送时的序号进行去重处理.

那么对于发送方而言,等待重传的时间如何确定?当这个时间过长会影响数据传输的效率,当时间过短可能会导致接收端会频繁接受重复的数据.所以TCP为了保证在任何环境下保持高性能的通信,会动态计算这个超时时间:且随着重传的失败,超时时间也会变长,当累计到一定的重传次数之后,TCP会强制关闭连接,减少资源损耗.
连接管理机制(安全机制)
1. 建立连接:三次挥手:发送方和接收方之间通过三次交互建立连接.首先客户端是主动发起连接的一方,客户端会发送一个SYN标记给服务器,请求建立连接.服务器在接受到SYN后会反馈一个ACK同时也发起一个SYN给客户端,客户端接收到服务器的反馈后会向服务器发送一个ACK.至此,客户端与服务器之间成功建立连接.
  如图所示,服务器发送的SYN和ACK是可以同时发送的,所以是"三次握手".可以同时发送的原因是因为SYN和ACK都是处于内核态,可以同时进行.因为数据的发送需要经过封装和分用,所以同时发送并分开发送两次的传输效率高. 三次握手的作用:投石问路,可以检测当前网络状况是否可以满足网络通信;双方之间可以协商一些重要的信息.
  TCP建立连接为什么是三次握手,不是两次或者四次?首先两次是肯定的不行的,因为客户端和服务器均需要发送一个SYN的标识和接收到对方SYN标识并反馈给对方的ACK标识;四次可以,但是不如三次的效率更高.
2. 断开连接:四次挥手:发送方和接收方之间通过四次交互断开连接.双方各自向对方发送一个FIN标识的报文段请求断开连接并反馈给对方一个ACK报文段.断开连接的首先发起者既可以是客户端也可以是服务器.
  
  可以看到,四次挥手的机制和三次握手的机制差不多,区别就在于中间的ACK和FIN不能合并发送.不能合并的原因会因为ACK和FIN发送的时机是不一样的,ACK是内核负责的,FIN则是在用户态中调用close()方法触发的.(ACK优先于FIN发送)当然中间两次操作在特殊情况下也是可以合并的,当两次操作的时间差比较小是会发生合并.
  这里介绍两种比较重要的状态:CLOSE_WAIT:指的是某一方接收到另一方的FIN标识并反馈ACK标识后等待用户态调用close()方法时的状态;TIME_WAIT:主动发起FIN的一方会在四次挥手后进入TIME_WAIT状态.表面上看当客户端发送完ACK之后就可以销毁连接的资源了,但需要考虑的是第四次挥手发送的ACK可能会发生丢包的现象,进而触发服务器的超时重传,如果提前关闭客户端,则无法接收到服务器的超时重传的数据段.所以进入TIME_WAIT状态的一方会在等待一个2*报文最大生存时间后才关闭.
滑动窗口机制(效率机制):在我们之前讨论的确认应答机制中,当发送方发送数据后,需要收到接收端的ACK才能继续发送下一个数据段.这样传输数据的效率是比较低的,尤其是当数据往返的时间比较长时.因此引入滑动窗口机制,意思是可以一次发送多个数据段.具体流程为:
1. 滑动窗口的大小指无需等待确认应答机制而可以发送数据的最大值.例如四个段.
2. 发送前四个段时可以直接发送,无需等待ACK.
3. 当收到四个段中的某个段的ACK之后,滑动窗口向后移动继续发送第五个段的数据.
4. 操作系统内核中会维护一个发送缓冲区来确保只有确认应答过的数据才能被删除掉.
  上述情况是数据正常发送的情况,下面讨论两种数据丢包的情况
- 接收方正常接收到数据包,但在反馈ACK时丢包了.这种情况下可以根据滑动窗口后续数据段的ACK进行确认
- 接收方没有接收到数据包.当某个数据段丢失后,接收方会一直向发送方反馈之前的确认序号,以告知发送方自己没有有一个数据段没有接收到.发送方收到这样的ACK之后会重新向接收方发送这一部分数据段.
流量控制机制(安全机制):接收端处理数据的速度是有限的,有些时候,发送端发送数据的速度过快导致接收方的接收缓冲区被占满,这个时候发送端再发数据就会造成丢包等现象.因此TCP支持根据接收端接收数据的能力来决定发送端的发送速度.发送端发送数据的速度取决于接收端接收缓冲区中剩余大小.具体流程:
1. 接收端会将自己的接收缓冲区的大小放入TCP首部的"窗口"字段,通过ACK反馈给发送端. 这个"窗口"也就是TCP首部的"16位窗口大小",当然这个缓冲区的大小不止65535位.在TCP首部40字节选项中还包含了一个窗口扩大因子M,实际缓冲区大小是窗口字段的值左移M位.
2. 当接收端发现自己的缓冲区中的数据快满了,就会减小窗口的值然后反馈给发送端,发送端依据此放慢自己的发送速度
3. 当接收端发现自己的缓冲区已经满了,就会将窗口的值设置为0,发送端根据这个值变为0后将不再发送数据,但会定期的发送一个窗口探测的数据段用来得到接收区中缓冲区的剩余大小.当接收端中缓冲区大小有剩余时,会向发送端发送一个窗口更新通知.
拥塞控制机制(安全机制):衡量发送方和接收方之间链路间的拥堵情况.在发送数据的时候,会通过中间多个设备的转发才能到达接收端.每个设备的网络拥堵情况是不确定的,因此我们需要去衡量链路间的拥堵情况以确定发送方的发送速率.我们用一个拥塞窗口来"实验".在发送开始的时候,拥塞窗口的大小为1,每当正常发送到接收端并收到ACK后拥塞窗口的大小会加1.在起初时,在网络正常的情况下拥塞窗口的大小是指数增长的.之后当达到一个阈值后会线性增长,当网络开始拥塞导致丢包会适当减小窗口的大小,然后继续去"实验"直到达到一个比较合适的拥塞窗口的大小.发送方在发送数据的时候发送的滑动窗口的大小是拥塞窗口大小和接收端缓冲区剩余大小的较小值.当发生超时重传后,拥塞窗口的大小会变为1.
延迟应答机制(效率机制):相当于流量控制的延伸.通过流量控制我们知道发送端发送速率取决于接收端接收缓冲的剩余大小.如果每次发送端发送数据接收端立即返回一个窗口大小,因为接收端处理数据的速度也是很快的,所以可能在发送端接收到ACK之前接收端中的缓冲区的大小已经变大了,所以为了让窗口尽可能的大,接收方在接收到数据后会延迟一定的时间再反馈ACK.延迟应答的次数和延迟时间依据不同的操作系统和数据包发送的个数有关.
捎带应答机制(效率机制):很多情况下接收端在接收到数据时会反馈一个ACK以及向发送方发送别的数据.而ACK是在内核中实现的,发送的数据则是在用户态的代码中实现的.因此ACK和发送的数据是不能同时发送的.但因为有了延迟应答,某个之前应该反馈的ACK因为延迟应答可能会和后面某个发送的数据同时封装然后一块发送过去,从而使得传输效率更高.

TCP的特点

有连接
可靠
面向字节流:因为面向字节流的特性,引出了另外一个问题:粘包问题.粘包中的包指的是应用层的数据包.TCP协议中没有像UDP一样"数据长度"的字段.只有一个序号的字段.在传输层中,数据包是一段一段发送并按照序号排到接收缓冲区中.但站在应用层的角度,在其向接收缓冲区中读取数据的时候,因为是面向字节流的,我们并不清楚从哪读到哪是一个完整的应用层数据包.为了解决粘包问题,我们需要给包和包之间建立"边界".如可以在每个包的包头设置一个该包的长度.或者通过";"等符号来分隔每个包.
全双工:在同一时刻某个主机既可以作为发送端也可以作为接收端.

TCP异常

进程终止:因为TCP的连接是通过socket建立的.而socket本质上是进程中打开的一个文件.当进程突然中之后,进程中的PCB块会被销毁,而PCB块中的文件描述符表也就被销毁,进而socket文件也会被关闭.
机器关机:当机器正常关机后,操作系统会将所有进程结束后再关闭机器,所以和进程终止的情况相同
机器断电,断网:因为机器突然关闭,操作系统没有足够的时间去将进程关闭.这时候会分成两种情况:
1. 发送端机器断电.接收端无法区分发送端是因为什么情况而导致不再发送数据.所以接收端会定时的发送一个探测报文(不带有实际数据,只是为了触发发送端的ACK),多次发送探测报文仍没有接收到发送端的ACK后,接收端会认为发送端发生了严重故障,接收端会主动释放连接
2. 接收端机器断电.发送方正常发送数据但没有收到ACK,然后会进入超时重传,当重传了几次之后发现接收端无反应则会认为接收端发生了严重故障,发送端就会主动释放连接.