第五讲：传输层协议介绍（三次握手、四次挥手）

文章目录

• 一、传输层协议介绍
• • 1、TCP协议概念
  • 2、UDP协议概念
• 二、TCP协议
• • 1、TCP协议介绍
  • 2、TCP报文段的格式
  • • 2.1 TCP报文段首部的格式
    • 2.2 各字段说明
  • 3、 TCP三次握手
  • • 3.1 三次握手步骤讲解
    • 3.2 为什么是三次握手，不是二次握手，也不是四次握手
    • • 3.2.1 为什么不是二次握手？
      • 3.2.2 为什么不是四次握手？
  • 4、TCP四次挥手
  • • 4.1 四次挥手步骤讲解
    • 4.2 为什么是四次挥手，不是三次挥手？
  • 5、TCP连接常用的端口号
• 三、UDP协议
• • 1、UDP报文段的格式
  • • 1.1 UDP报文段首部
    • 1.2、各字段解释
  • 3、UDP连接常用的端口

一、传输层协议介绍 1、TCP协议概念

●面向连接网络协议

●是指通信双方之间在进行通信之前要先建立连接。比如打电话，双方通话前要先建立连接。

●TCP协议是面向连接的，可靠的进程到进程通信的协议，TCP提供全双工服务，即数据可在同一时间双向传输，每一个TCP都有发送缓存和接收缓存，用来临时存储数据。

2、UDP协议概念

●面向无连接网络协议

●是指通信双方不需要事先建立一条通信线路，而是把每个带有目的地址的包送到网络线路上，由系统自主选定路线进行传输，比如：QQ发送消息

●UDP协议是无连接的、相对于TCP是不可靠的传输层协议，发送端不关心发送的数据是否到达目标主机、数据是否出错等，收到数据的主机也不会告诉发送方是否收到了数据，它的可靠性由上层协议来保障。所以它的传输数据的速度更快，效率更高。

二、TCP协议 1、TCP协议介绍

●TCP是面向连接的、可靠的进程到进程通信的协议

●TCP提供全双工服务，即数据可在统一时间双向传输

●TCP报文段

TCP将若干个字节构成一个分组，叫报文段（Segment）

2、TCP报文段的格式 2.1 TCP报文段首部的格式

2.2 各字段说明

①源端口号（16bit）：发送方进程的端口号

②目标端口号（16bit）：接收端进程的端口号

解释：接收端受到数据段后，根据这个端口号来确定把数据送给哪个应用程序的进行

③序号（32bit）：发送端为每个字节进行编号，便于接收端正确重组。

解释：当TCP从进程接收数据字节时，把它们分片成数据段存储在发送缓存中，并对每一个字节进行编号。当数据到达目的地后，接收端会按照这个序号将数据重新排列，保证数据的正确性。

④确认号（32bit）：对发送端的确认信息

解释：接收端响应消息时，将会用它来告诉发送端这个序号之前的数据段都已经收到，如果确认号是x，就是表示前x-1个数据段都已经收到。

⑤首部长度（4bit）：用它可以确定TCP首部数据结构的字节长度。一般情况下TCP首部是20字节，但是首部长度最大可以扩展为60字节

⑥控制位（6bit）：每一个特殊状态的标识

●URG：紧急位。

解释：当URG=1时，标明紧急指针有效（要和紧急指针配合使用）。它告诉系统此报文段中有紧急数据，应尽快传送，把紧急数据插入到本报文段数据的最前面。相当于高优先级的数据。

●ACK：确认位。

解释：当ACK=1时，确认号字段才有效，当ACK=0时，确认号无效，TCP中规定，在连接建立之后所有的传送的报文段都必须把ACK置为1.

●PSH：急迫位。

解释：在两个应用进程通信时，发送端希望接收端能立即响应，这时，TCP就可以使用急迫位PSH *** 作，发送时将PSH=1，并立即创建一个报文段发送出去，接收方收到PSH=1,就尽快的交付接收应用进程，而不再等整个缓存都填满了再向上交付。

●RST：重置位。

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

●SYN：同步位。

解释：再连接建立时用来同步序号。当SYN=1时，且ACK=1时，表示这是一个连接请求报文段。对方若同意连接，则在响应的报文段中SYN=1和ACK=1，

●FIN：断开位。

●解释：终止一个连接，当FIN=1时，表示此报文段发送方的数据以及发送完毕，并且要求释放传输连接。

⑦窗口大小（16bit）：说明本地可接收数据段的数目。

解释：这个值大小是可以变的，当网络通畅时，接收端响应消息会将这个窗口值变大以加快传输速度，当网络不稳定时，减少这个值可保证网络数据的可靠传输。

⑧检验和（16bit）：用来做差错校验

解释：字段检验的范围包括首部和数据这两个部分。数据段在发送时和到达目的地时，会进行校验和计算。若两次校验和一致，则说明数据基本正确，若不一致，则认为该数据已损坏，接收端将丢弃该数据

⑨紧急指针（16bit）：配合URG使用，当URG=1时有效。

⑩选项：在TCP首部可以有多大40字节的可选信息。

3、 TCP三次握手

TCP是面向连接的协议，就是说每次发送数据之前都要和对方建立一条可靠的连接，这个建立连接的过程分为3个步骤，就叫三次握手。

3.1 三次握手步骤讲解

①当客户端向服务器发送请求连接的报文时

●Seq序列号=x（x位随机）

●SYN=1（表示发送连接请求）

②服务端收到客户端发来的请求报文后，同意建立连接，则向客户端发送确认报文

●Seq序列号=y（这时服务器也会产生一个序列号y，和客户端的序号不相关）

●Ack确认号=x+1（这时序列号x+1，表示确认收到了客户端的请求）

●ACK=1（表示这是条确认请求）

●SYN=1（同时也发送一个建立连接的请求）

③客户端进程收到服务端进程的确认后，还要想服务端给出确认，然后连接成功建立

●Seq序列号=x+1（这时客户端的序号为1）

●Ack确认号=y+1（表示收到服务器的连接请求）

●ACK=1（表示这时确认报文）

3.2 为什么是三次握手，不是二次握手，也不是四次握手

●参考文献：TCP 为什么是三次握手，而不是两次或四次？ - 知乎 (zhihu.com)

●谢希仁文章《计算机网络》中说明“三次握手”的目的是

“为了防止已失效的连接请求报文段突然又传到服务端，因而产生错误”

●解释：客户端发送的第一个连接请求报文段没有丢失，而是在网络中滞留了，滞留了一段时间后到达服务端，这本来是一个早已失效的报文段，结果服务端认为这是客户端发过来的连接请求，然后随即向客户端发送同意建立连接。如果不采用“三次握手”那么只要服务端发出同意连接后，就会建立连接了，由现在的客户端并没有向服务端发出连接请求，但是服务端还在等待客户端发送数据，这样，服务端很多资源就会被浪费掉。所以才用“三次握手”就可以防止上述现象出现。

3.2.1 为什么不是二次握手？

●假设是二次握手

**第一次握手：**客户端向服务端发送序号Seq=x和SYN=1，请求连接

**第二次握手：**服务端收到客户端恢复Seq=y和Ack=x+1，以及SYN=1和ACK=1，回复连接，并请求连接

●说明：TCP为了保证在不稳定的网络环境中构建一个稳定的数据连接，它就需要一个“序列号”字段来保证自己的稳定性，而这个序号的作用就是防止数据包重复发送，以及有效的解决数据包接收时顺序颠倒的问题

●二次握手这里就会有一个问题，客户端与服务端对客户端的序号达成一致，但是服务端无法知道客户端是否收到了之间的同步信号，假如这个同步信号丢失了（第三次握手），客户端和服务端就对于服务端的序列号无法达成一致。

●于是，后面就将SYN也设计成占用一个字节的编号，既然SYN也占用一个字节，那么客户端就必须给服务端一个确认，表示客户端已经收到了服务端的同步信号。

3.2.2 为什么不是四次握手？

●假设是四次握手

**第一次握手：**客户端向服务端发送序列号：Seq=x和SYN=1,申请连接

第二次握手：服务端回复客户端Ack=x+1，ACK=1，确认连接申请

第三次握手：服务端向客户端发送序列号：Seq=y和SYN=1，申请连接

第四次握手：客户端回复服务端：Ack=y+1和Seq=x+1，ACK确定连申请

●很明显，第二次握手和第三次握手两个步骤可以合并，所以只需要三次握手，可以提高连接的速度与效率。

●问题：第一次握手丢失了怎么办？

客户端向服务端申请建立连接SYN=1,Seq=x,丢失了，会触发客户端的重传机制，导致客户端会持续发送建立连接请求，知道服务端回复ACK或者一定时间后断开。

●问题：第二次握手丢失了怎么办？

服务端向客户端申请建立连接，并且回复客户端的连接申请：Seq=y，Ack=x+1，ACK=1,SYN=1，丢失了，此时会引发客户端与服务两台服务器的重转机制，

客户端：认为自己的第一次握手对方没有收到（因为没有收到ACK=1），会持续发送连接申请

服务端：认为自己的第二次握手对方没有收到，会持续发送

●问题：第三次握手丢失了怎么办？

客户端向服务端回复连接申请，ACK=1，Seq=x+1，Ack=y+1，丢失了，服务器会认为自己发送的第二次握手没到到达，会一直发送。

4、TCP四次挥手 4.1 四次挥手步骤讲解

①当客户端向服务器发送断开请求

●FIN=1(表示申请断开请求)

●ACK=1(表示确认可以断开)

②服务器收到断开请求后回复确认信息

●ACK=1（表示确认可以断开）

③服务器再向客户端发送断开请求

●FIN=1（表示申请断开请求）

●ACK=1（表示确认可以断开）

④客户端收到断开请求后恢复确认信息

●ACK=1（表示确认可以断开）

4.2 为什么是四次挥手，不是三次挥手？

**第一次挥手：**客户端向服务端发送断开请求：FIN=1,ACK=1。

表示客户端已经没有数据需要再发送给服务端了，此时进入到等待状态，

第二次挥手：服务端向客户端回复断开请求：ACK=1。

表示服务端已经同意断开连接，但是不能立即断开，可能还有一些数据没有发送完成

第三次挥手：服务端向客户端发送断开请求：FIN=1,ACK=1。

表示服务端也没有数据向客户端进行发送了，申请断开连接，此时进入到等待状态

第四次挥手：客户端向服务端回复断开请求：ACK=1。

表示客户端同意服务端的断开请求，等待一段时间后，进行关闭。

以上：为什么第二次挥手和第三次挥手不进行重合，在三次握手中，这一步就进行了重合，那是因为在第二次挥手时，服务端必须要给客户端做出应答，不然客户端就会一直给服务端发出断开申请，但是做出回答之后又不能立即申请断开连接，因为可能服务端还有一些数据没有发完，所以需要等待一段时间后才能发出断开申请。

●问题：如果第一次挥手丢失了怎么办？

客户端向服务端发送断开申请，FIN=1，ACK=1，丢失了，那么会触发TCP的重传机制，会持续一直发送，如果长时间不回则自动断开，或则等到服务端进行发送。

●问题：如果第二次挥手丢失了怎么办？

服务端向客户端回复断开申请，ACK=1，丢失了，因为ACK没有重转机制，此时也会触发客户端的重传机制，会再持续发送断开申请。

●问题：如果第三次挥手丢失了怎么办？**

跟第一次挥手一样效果

●问题：如果第四次挥手丢失了怎么办？

跟第二次挥手一样效果

5、TCP连接常用的端口号

端口	协议	说明
21	FTP	FTP服务器所开放的控制端口（文件传输协议—面向文件）
23	TELNET	用于远程登录，可以远程控制管理目标计算机
25	SMTP	SMTP服务器开放的端口，用于发送邮件
80	HTTP	超文本传输协议，明文发送（面向网页）
443	HTTPS	超文本传输协议，密文发送（面向网页）
110	POP3	用于邮件的接收

三、UDP协议

●UDP是无连接、快速、效率高的传输协议

●UDP相对TCP来说，不够可靠的协议

1、UDP报文段的格式 1.1 UDP报文段首部 1.2、各字段解释

●UDP长度：用来支指UDP的总长度，为首部长度加上数据长度

●校验和：用来完成对UDP数据的差错校验，它是UDP协议提供的唯一的可靠机制

3、UDP连接常用的端口

端口	协议	说明
69	TFTP	简单文本传输协议
111	RPC	远程过程调用协议
123	NTP	网络时间协议