TCP、UDP协议_udp的长度为啥是4的倍数

目录

UDP

UDP - 数据格式

 端口（Port）

TCP

TCP - 数据格式

TCP的几个要点

可靠传输

流量控制

拥塞控制

连接管理

---

本文是根据小码哥的网络协议课程做的笔记

传输层有两个协议

TCP（Transmission Control Protocol），传输控制协议

UDP（User Datagram Protocol），用户数据报协议

UDP

UDP - 数据格式

---

UDP是无连接的，减少了建立和释放连接的开销。UDP尽最大能力交付，不保证可靠交付。因此不需要维护一些复杂的参数，首部只有8个字节（TCP的首部至少20个字节）

 UDP长度占16位，首部的长度+数据的长度

检验和的计算内容：伪首部+首部+数据

伪首部：仅在计算检验和时起作用，并不会传递给网络层

 端口（Port）

---

UDP首部中端口是占用2字节，可以推测出端口号的取值范围是：0~65535

客户端的源端口是临时开启的随机端口，一旦这一次请求结束了，这个端口可能就不占用了。服务器的端口要一直开着

防火墙可以设置开启\关闭某些端口来提高安全性

常见的一些协议默认使用的端口：

访问数据库时，为了安全起见，通常用防火墙关闭3306端口，先访问HTTP，再在内部发请求给mysql

常用命令行

netstat -an：查看被占用的端口

netstat -anb：查看被占用的端口，占用端口的应用程序

telnet 主机 端口：查看是否可以访问主机的某个端口

安装telnet：控制面板 - 程序 - 启用或关闭Windows功能 - 勾选 "Telnet Client" - 确定

TCP

TCP - 数据格式

---

数据偏移

占4位，取值范围是0x0101~0x1111

乘以4：首部长度（Header Length）

首部长度是20~60字节，由于首部长度至少是20个字节，所以数据偏移最小取值是5。首部长度可用于计算右面的TCP数据部分的偏移长度

保留

占6位，目前全为0

TCP的几个要点

---

可靠传输

流量控制

拥塞控制

连接管理  建立连接 释放连接 

TCP - 小细节

 有些资料中，TCP首部的保留（Reserved）字段占3为，标志（Flags）字段占9位。Wireshark中也是如此

UDP的首部中有个16位的字段记录了整个UDP报文段的长度（首部+数据），但是，TCP的首部中仅仅有个4位的字段记录了TCP报文的首部长度，并没有字段记录TCP报文段的数据长度。原因是UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐。而TCP\UDP的数据长度，完全可以由IP数据包的首部推测出来。

传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度

为什么要保证对齐呢，因为经常会有一个二进制的值，要乘以4才是最终的值，如数据偏移字段。所以要保证长度是4的倍数。

TCP - 检验和（Checksum）

跟TCP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据

伪首部：占用12字节，仅在计算检验和时起作用，并不会传递给网络层

 TCP - 标志位

URG(Urgent)

当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK(Acknowledgment)

当ACK=1时，确认号字段才有效

PSH(Push)

RST(Reset)

当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接

SYN(Synchronization)

当SYN=1,ACK=0时，表明这是一个建立连接的请求

若对方同意建立连接，则回复SYN=1，ACK=1

FIN(Finish)

当FIN=1时，表明数据已经发送完毕，要求释放连接

TCP - 序号，确认号，窗口

序号（Sequence Number）

占4字节。首先，传输过程中的每一个字节都会有一个编号。在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号

确认号（Acknowledgment Number）

占4字节。在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节编号

窗口（Window）

占2字节。这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

可靠传输

---

TCP可靠传输 - 停止等待ARQ协议

ARQ(Automatic Repeat-reQuest)，自动重传请求

 

 由于停止等待协议效率较低，于是有了连续ARQ协议和滑动窗口协议

TCP可靠传输 - 连续ARQ协议 + 滑动窗口协议

如果接收窗口最多能接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包？等待一定时间后没有第3个包，就会返回确认收到2个包给发送方

 现在假设每一组数据是100字节，代表一个数据段的数据。每一组数据在发出去时，都会带有自己的首部。每一组给一个编号。

TCP可靠传输 - SACK（选择性确认）

在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1，2，3，4，5中的3丢失了）

TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3，4，5）

这样原先已经正确传输的分组也可能会重复发送（比如4，5），降低了TCP性能

为改善上述情况，发展出了SACK(Selective Acknowledgment，选择性确认）技术

告诉发送方哪些数据丢失，哪些数据已经提前收到

使TCP只重新发送丢失的包（比如3），不用发送后续所有的分组（比如4，5）

SACK信息会放在TCP首部的选项部分，由于选项中可以放很多种数据格式，怎么确认是SACK呢，就需要Kind字段来判断。Kind占1字节，值为5代表这是SACK选项，Length占1字节，表明SACK选项一共占用多少字节。Left Edge：占4字节，左边界，Right Edge：占4字节，有边界

 一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以SACK选项再多携带4组边界信息，SACK选项的最大占用字节数=4*8+2=34

若有个包重传了N次还是失败，会一直持续重传到成功为止吗？这个取决与系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接。

为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层呢？因为可以提高重传的性能。需要明确的是：可靠传输是在传输层进行控制的。如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传，如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可。

流量控制

如果接收方的缓存区满了，发送方还在疯狂地发送数据，接收方只能把收到的数据包丢掉。大量的丢包会极大地浪费网络资源，所以要进行流量控制。

什么是流量控制？让发送方的发送速率不要太快，让接收方来得及接收处理。

原理是通过确认报文中窗口字段来控制发送方的发送速率，发送方的发送窗口大小不能超过接收方给出窗口大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据。

特殊情况

有一种特殊情况，一开始，接收方给发送方发送了0窗口的报文段。后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了。发送方的发送窗口一直为零，双方陷入僵局。

解决方案：当发送方收到0窗口通知时，这时发送方停止发送报文。并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小。如果接收的窗口大小还是为0，则发送方再次刷新启动定时器。

拥塞控制

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

拥塞控制是一个全局性的过程，涉及到所有的主机，路由器，以及与降低网络传输性能有关的所有因素，是大家共同努力的结果。相比而言，流量控制是点对点通信的控制。

方法

慢开始（slow start，慢启动）

拥塞避免（congestion avoidance）

快速重传（fast retransmit）

快速恢复（fast recovery）

下文用到的几个缩写：

MSS(Maximum Segment Size)：每个段最大的数据部分大小。在建立连接时确定。

传输层是分段(segment)，网络层是包(packet)，数据链路层是帧(frame)。

cwnd(congestion window)：拥塞窗口

rwnd(receive window)：接收窗口

swnd(send window)：发送窗口 swnd=min(cwnd,rwnd)

慢开始

cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK）

cwnd就成倍增长（指数级）

拥塞避免

ssthresh(slow start threshold)：慢开始阈值，cwnd达到阈值后，以线性方式增加

拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞

乘法减小：只要网络出现拥塞，把ssthresh减半，与此同时，执行慢开始算法（cwnd又恢复到初始值）

快重传

接收方每收到一个失序的分组后就立即发出重复确认，使发送方及时知道有分组没有到达，而不要等待自己发送数据时才进行确认

发送方只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期后再重传

快重传+快恢复

快恢复

当发送方连续收到三个重复确认，就执行”乘法减小“算法，把ssthresh减半。这是为了预防网络发生拥塞，因为丢包可以预测网络拥塞。

由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值，而是把cwnd值设置为ssthresh减半后的数值，然后开始执行拥塞避免算法（”加法增大“），使拥塞窗口缓慢地线性增大。

发送窗口的最大值

发送窗口的最大值：swnd = min(cwnd,rwnd)

当rwnd<cwnd时，是接收方的接收能力限制发送窗口的最大值

当cwnd<rwnd时，则是网络的拥塞限制发送窗口的最大值

连接管理

在发送请求之前，会先建立连接

 序号，确认号

 

 

 

初始序号加相对值是真实的序号

初始序号是随机生成的，123456是假定客户端生成的初始序号，23456是假定服务器端生成的初始序号。

下面用s1代表客户端生成的初始序号，s2代表服务器生成的初始序号。

紫色代表客户端，蓝色代表服务器端

前三步都是只有头部的，没有数据部分

由于ack是告诉对方我收到了多少并且希望对方从哪里开始发，所以服务器的ack加1

syn为1代表这是一个请求建立的报文，只有前两个为1，后面都为0了。

 

 

 为什么第三步和第四步的ack都为1呢？因为都是客户端发送的数据，ack是响应上一次别人发过来的，这两步的上一次的seq都是0。seq是1是因为上一次的ack是1，别人希望你从第一个字节开始发

由于5是服务器给客户端发的第一个数据，所以seq从1开始

这四步都是服务器给客户端发的，ack都是代表收到客户端发的k字节数据，请求从第k+1开始的数据。

第n个包的序号 = 前面n-1个包的总长度 + 1

 这一步客户端给服务器发数据，由于之前服务器的ack都返回k+1，于是客户端的seq为k+1，但是没有发数据。

3次握手 

状态解读

CLOSED：client处于关闭状态

LISTEN：server处于监听状态，等待client连接

SYN-RCVD：表示server接收到了SYN报文，当收到client的ACK报文后，它会进入ESTABLISHED状态

SYN-SENT：表示client已发送SYN报文，等待server的第2次握手

ESTABLISHED：表示连接已经建立

前2次握手的特点

SYN都设置为1，数据部分的长度都为0。

TCP头部的长度一般是32字节。固定头部20字节，选项部分12字节。

双方会交换确认一些信息，比如MSS，是否支持SACK，Window scale（窗口缩放系数）等。这些数据都放在了TCP头部的选项部分中（12字节）。

疑问

为什么建立连接的时候，要进行3次握手？2次不行吗？

主要目的：防止server端一直等待，浪费资源。

如果建立连接只需要2次握手，可能会出现的情况

假设client发出的第一个连接请求报文段，因为网络延迟，client迟迟收不到来自server的syn=1的包，这时client就会再发一次syn=1的包，建立连接。在连接释放以后的某个时间第一个连接请求报文段才到达server。

本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为client再次发出的一个新的连接请求，于是server就向client发出确认报文段，同意建立连接。

如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据。

但server却认为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了。

采用“三次握手”的办法可以防止上述现象发生。

例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接。

第3次握手失败了，会怎么处理？

此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK的包。如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接。

---

在一些开发过程中，为了防止因客户端突然断连使服务器消耗资源。会在客户端和服务器建立连接后，为使连接连续保活，会每隔一段时间发送数据包，如每隔5s发一个包，叫心跳包。

释放连接 - 4次挥手

 疑问

为什么释放连接的时候，要进行4次挥手？

TCP是全双工模式

第1次挥手：当主机1发出FIN报文段时，表示主机1告诉主机2，主机1已经没有数据要发送了，但是此时主机1还是可以接受来自主机2的数据。

第2次挥手：当主机2返回ACK报文段时，表明主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的。

第3次挥手：当主机2也发送了FIN报文段时，表示主机2告诉主机1，主机2已经没有数据要发送了。

第4次挥手：当主机1返回ACK报文段时，表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接。

状态解读

FIN-WAIT-1：表示想主动关闭连接 。向对方发送了FIN报文，此时进入到FIN-WAIT-1状态。

CLOSE-WAIT：表示在等待关闭。当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态。在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方。

FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文

CLOSING：一种比较罕见的例外状态。表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态。表示双方都正在关闭连接。

LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，即可进入CLOSED状态了。

TIME-WAIT：表示收到了对方的FIN报文，并发送了ACK报文，就等2MSL后即可进入CLOSED状态了。如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态。

CLOSED：关闭状态

由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD，FIN-WAIT-1等

细节

TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开。

client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接。

一般是等待2倍的MSL(Maximum Segment Lifetime，最大分段生存期)。

MSL是TCP报文在Internet上的最长生存时间

每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟。

假设第三次 ACK发送后client关闭了，这个端口被另外一个程序占用。但是这个ACK还没有到达服务器，这时候因为超时重传，这个服务器又会发一次FIN，就会发到另外一个程序处。因此2MSL 可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在2MSL(一次来回) 时间内消失了）。

如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN。这时可能出现的情况是

1. client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源。

2. client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的。

这个阶段就是用来等服务器发FIN的。

抓包

有时候在使用抓包工具的时候，有可能只会看到“3次”挥手

这其实是将第2，3次挥手合并了

当server接收到client的FIN时，如果server后面也没有数据要发送给client了

这时，server就可以将第2，3次挥手合并，同时告诉client两件事：

1. 已经知道client没有数据要发

2. server已经没有数据要发了

 

我们常常提到的长连接和短连接是如何区分的？

建立连接后，收发数据完就释放连接的是短连接，做完数据交互后还在等待收发数据，不马上释放连接的是长连接。