传输层之UDP与TCP的首部

从通信信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能的最底层。

传输层位于应用层和数据链路层之间,主要有两个协议,用户数据报协议UDP(User Datagram Protocol)、传输控制协议TCP(Transmission Control Protocol)。

UDP在发送数据前不需要建立连接,所以首部不需要存储太多数据,只有四部分(源端口、目的端口、长度、检验和),各占2个字节,其中长度属性并没必要,因为完全可以在数据链路层计算出来,这里存在是为了保障头部占据8字节。

这里增加了一个【伪首部】,伪首部的数据是不会发送到下一层的,仅仅是用于检验和增强校验的功能,检验和将首部(包括伪首部)和数据部分一起计算。

UDP请求抓包后可以看到只有几项数据,源端口52364,目的端口53,总长度43字节,检验和看起来无效。

但TCP就不同了,发送数据前需要建立连接,并且尽可能的保障数据可靠交付,首部会有更多的属性来记录信息。

  • 序号(Sequence Number) --- 4字节, TCP传输过程中每一个字节都有编号,建立连接后,序号表示TCP数据部分的第一个字节编号(实际是一个非常大的值,非常大的值 - 固定值 = 小的编号,同一请求有一个固定值,固定值来源于建立连接时seq=0时的值)
  • 确认号(Acknowledgment Number) --- 期望对方下一次传过来的TCP数据部分的第一个字节编号
  • 数据偏移 --- 4位,范围0x0101-0x1111,换成十进制乘以以4为首部长度(20-60字节)
  • 保留 --- 暂时没什么用,占6位(标志位有三位没什么用就划到了保留位中),有些资料会说占3位,标志位占9位
  • 标志位(Flags) --- 6位
    • URG: urgent(紧急)--- 为1时,紧急指针中的数据才有作用
    • ACK: acknowledgment(确认)--- 为1时,确认号字段才有效
    • PSH: push --- 交互式网络通信才有用
    • RST: reset(重置)--- 为1时,表示tcp连接中出现问题,要释放连接并重新建立连接
    • SYN: synchronization(同步,用于建立连接)--- syn=1,ack=0时表明建立连接,服务器同意时回复syn=1,ack=1
    • FIN: finish(终止连接)--- 为1时,表示要求释放连接
  • 窗口(Window) --- 2字节,流量控制功能,告知下一次允许发送的数据大小
  • 检验和(checksum) --- 2字节,计算伪首部(12字节、不会传递给网络层) + 首部 + 数据
  • 紧急指针: 2字节,urg为1时生效,放置的是长度,表示tcp数据中前x位是紧急数据,尽快传送
  • 选项:长度可变,当建立连接时,可靠传输和流量控制时需要

从抓包数据可以看到,序号为0,但它真实的序号是一个非常大的数字(631127820),确认号为0,数据偏移为8,乘以4得出的首部长度为32字节,标志位折叠起来了,里面的syn是1,其余都是0,这里是建立连接的时候。

窗口大小64240,检验和看起来无效,紧急指针为0,选项中有12字节,里面定义了一些建立连接需要用的其它数据,加上首部其他属性的默认20字节,与总长度32字节对应。

首部存储信息的不同决定着UDP和TCP存在很大的差异。

UDP适合实时的场景,比如直播、视频通话,即使有些时候卡顿,没听清内容、没看到画面,也不影响通信的正常进行。

TCP正好相反,适用于需要数据完整的场景,比如邮件、浏览器、文件传输等,这些场合如何丢失了一些文字和数据,可能语义就完全变了,会对内容完整性有较大影响。

而TCP又如何做到保障数据的可靠传输呢?敬请期待我下一篇文章~

以上就是 传输层之UDP与TCP的首部的内容 , 更多有关 前端网络协议 的内容可以参考我其它的博文,持续更新中~

posted @ 2022-10-22 22:15  一颗冰淇淋  阅读(167)  评论(0编辑  收藏  举报