文章目录

• 1.TCP协议介绍
• 2.TCP报文格式
• 3.TCP三次握手
• • 3.1 三次握手的建立
  • 3.2 第三次握手的必要性
  • 3.2 SYN 攻击
• 4.TCP四次握手
• • 4.1 四次握手的释放
  • 4.2 为什么要有第四次挥手？
• 5.UDP协议
• • 5.1 UDP协议介绍
  • 5.2 UDP报文首部格式
  • 5.3 TCP Vs UDP
  • 5.2 常见协议端口号及其功能

1.TCP协议介绍

1. 传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
2. TCP面向连接网络协议，是指通信双方之间在进行通信之前要先建立连接。比如打电话，双方通话前需要先建立连接。
3. TCP提供全双工服务，即数据可在同一时间双向传输，每一个TCP都有发送缓存和接收缓存，用来临时存储数据。

2.TCP报文格式

TCP头部

• 固定首部部分
  一共20个字节，在图中分为五行，每行四个字节，也就是32位。
• 长度不定的可选字段
  可选字段的长度不定，意味着TCP头部的长度是可变的。

字段详解

第一行：源端口号和目的端口号
TCP源端口（Source Port）：源计算机上的应用程序的端口号，占16位（bit）
TCP目的端口（Destination Port）：目标计算机的应用程序的端口号，占16位（bit）

第二行：序列号
TCP序列号（Sequence Number）：占32位（bit），表示本报文段所发送数据的第一个字节的编号。在TCP连接中，所传送的字节流的每一个字节都会按顺序编号。

思维拓展如下所示：
比如分组的第一个数据包由文件的14个字节数据组成，那么该数据包所添加的序号就是1。同理，第二个数据包由文件的59个字节数据组成，那么该数据包所添加的序号是多少呢？
解析如下所示：
序号1：字节1-14；
序号2：字节15-28；
序号3：字节29-42；
序号4：字节43-56；
序号5：字节57-70；
因此，该59个字节数据包所添加的序号就是5。

第三行：确认号
TCP确认号：占32位（bit），表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。

第四行：（顺序如图从左到右）
数据偏移（即首部长度，Header Length）：
占4位（bit），它指出 TCP 报文段的，数据起始处距离 TCP 报文段的起始处有多远，也就是TCP首部的长度。

“数据偏移”的单位是 32 位字（以 4 字节为计算单位），最大1111表示15x4=60个字节，即表示TCP首部最大长度为60个字节，因此TCP首部的“可选字段”部分最多40个字节。

保留字段（Reserved）：占 4 位。为 TCP 将来的发展预留空间，目前必须全部为 0。

标志位字段：
URG（Urgent）：表示本报文段中发送的数据是否包含紧急数据。URG=1 时表示有紧急数据。当 URG=1 时，后面的紧急指针字段才有效。

ACK:表示前面的确认号字段是否有效。ACK=1 时表示有效。只有当 ACK=1 时，前面的确认号字段才有效。TCP 规定，连接建立后，ACK 必须为 1。

PSH（Push）：告诉对方收到该报文段后是否立即把数据推送给上层。如果值为 1，表示应当立即把数据提交给上层，而不是缓存起来。

RST：表示是否重置连接。如果 RST=1，说明 TCP 连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。

SYN：在建立连接时使用，用来同步序号。
当 SYN=1，ACK=0 时，表示这是一个请求建立连接的报文段。
当 SYN=1，ACK=1 时，表示对方同意建立连接。

SYN=1 时，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中 SYN 才为 1。

FIN：标记数据是否发送完毕。如果 FIN=1，表示数据已经发送完成，可以释放连接。

窗口大小字段（Window Size）：
占16位，TCP流量控制，表示目前还有多少空间，能接收多少数据量。

第五行：
TCP 校验位（TCP Checksum）：
占 16 位。它用于确认传输的数据是否有损坏。发送端基于数据内容校验生成一个数值，接收端根据接收的数据校验生成一个值。两个值必须相同，才能证明数据是有效的。如果两个值不同，则丢掉这个数据包。

紧急指针（Urgent Pointer）：
占 16 位。仅当前面的 URG 控制位为 1 时才有意义，它指出本数据段中为紧急数据的字节数，当所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。

第六行：可选项字段
可以自定义头部字段，长度不定，但长度必须是 32bits 的整数倍，最多40个字节。

第七行：TCP数据
数据部分(可以不发送任何数据)。

3.TCP三次握手

3.1 三次握手的建立

建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。
                 TCP连接的建立（“三报文”握手）

第一次握手：客户端将标志位SYN设置为1，随机产生一个Seq=x，向服务端发送请求连接。此时客户端处于同步已发送状态（SYN-SEND），等待服务端响应。
第二次握手：服务端收到请求之后，由标志位SYN知道客户端请求建立连接。服务端将标志位SYN和ACK都置为1，随机产生一个Seq=y,Ack=x+1，再发送数据包给客户端以确认连接请求，此时服务端处于同步已接收状态（SYN-RCVD）。
第三次握手：客户端收到请求之后，检查ACK是否为1，Ack是否为x+1，如果是则将标志位ACK置为1，Ack=y+1，并将该数据包发送给服务器，服务器检查ACK是否为1，并且Ack是否为y+1，如果正确则建立连接成功。客户端和服务端进入连接已建立状态（ESTABLISHED），可以进行数据传输。

三次握手的简化理解：客户端与服务器端三次握手建立连接的过程，可以类比为A和B进行语音通话。
首先，A对B发送一个（SYN）请求建立联系的报文：喂，你能听到吗？
其次，B对A回应一个（SYN+ACK）请求和确认报文：我能听到，你呢？
然后，A对B回复一个（ACK）报文：我也能。
最后，A和B进入正常通信状态。

3.2 第三次握手的必要性

两次握手，一次是客户端向服务端发出连接请求，此时只能是客户端向服务端发送数据，而服务端不能向客户端发送数据；
第二次是服务端向客户端发送的连接请求，这次过后双方都可以发送数据了；那其实两次连接就能解决问题，为什么还要建立第三次连接呢？（详细图解如下所示）

如果是两次握手，结束之后客户端和服务端都处于连接已建立状态（ESTABLISHED）；

建立好连接之后可以进行数据传输；

传输完之后通过四次挥手释放连接，客户端和服务端都处于关闭状态（CLOSED）；

此时如果传输过程中已经失效的连接请求报文段，突然又传送到了服务端，服务端会认为这是客户端发起的TCP请求，向客户端发送建立连接请求，此时服务端处于连接已建立状态；

该建立连接请求到达客户端后，由于客户端没有发起连接建立请求并且客户端处于关闭状态，因此不会理睬该报文段，但是服务端认为数据传输连接已经建立好了，会一直等待客户端发来数据，这样服务器的资源就被浪费了。

为了解决上面的情况，就引入了第三次握手。当客户端在收到应答报文段后，没有向服务端再次发送确认报文，视为此次连接建立失败。

3.2 SYN 攻击

在三次握手过程中，服务端发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接（half-open connect），此时服务端处于同步已接收状态（SYN_RCVD），当收到ACK后，服务端转入连接已建立状态（ESTABLISHED）。

SYN攻击就是客户端在短时间内伪造大量不存在的IP地址，并向服务端不断地发送SYN包，服务端回复确认包，并等待客户端的确认，由于源地址是不存在的。因此，服务端需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击是一种典型的DOS攻击，当服务端上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了。

4.TCP四次握手

4.1 四次握手的释放

                     TCP连接的释放（“四报文”挥手）

由于TCP连接是全双工的。因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，（客户端）发送一个FIN来终止这一方向的连接，（服务端）收到一个FIN只是意味着（客户端）这一方向上没有数据流动了，即（客户端）不会再收到数据，但是在这个TCP连接上（服务端）仍然能够发送数据，直到（服务端）这一方向也发送了FIN。
首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

第一次挥手：客户端发送一个FIN/ACK报文，用来关闭客户端到服务端的数据传送，客户端进入终止等待1（FIN_WAIT_1）状态。
第二次挥手：服务端收到FIN后，发送一个ACK报文给客户端，确认序号Ack为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入关闭等待（CLOSE_WAIT）状态。
第三次挥手：服务端发送一个FIN+ACK报文，用来关闭服务端到客户端的数据传送，服务端进入最后确认（LAST_ACK）状态。
第四次挥手：客户端收到FIN后，客户端进入时间等待（TIME_WAIT）状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入关闭（CLOSED）状态，完成四次挥手。

4.2 为什么要有第四次挥手？

一方没有信息发送了，但另一方还有信息要发送；所以，当一方发送FIN时，另一方发送ACK，然后接着再发送一个FIN+ACK报文。

为什么在最后一次挥手后要等待2MSL的时间？

保证客户端的最后一次挥手（ACK报文段）能够到达服务端。

服务端发送连接释放请求到客户端后(第三次握手)，进入最后确认（LAST-ACK）状态，客户端收到该请求之后发送确认报文段到服务端，进入关闭状态，然而该确认报文段丢失了，服务端必然会发生超时重传，并处于最后确认状态，客户端一直处于关闭状态，不会理睬该报文段。服务端会一直发送连接释放请求，无法进入关闭状态。

客户端在发送完最后一个报文段后，经过2MSL的时间可以使本次连接持续时间内所产生的所有报文段从网络中消失。这样下一个新的TCP连接中就不会产生旧的报文段。

5.UDP协议

5.1 UDP协议介绍

• 无连接、不可靠的传输协议
• 花费开销小

5.2 UDP报文首部格式

• UDP长度：用来指出UDP的总长度，为首部加上数据；
• 校验和：用来完成对UDP数据的差错检验，它是UDP协议提供的唯一的可靠机制。

5.3 TCP Vs UDP

5.2 常见协议端口号及其功能