目录
1.1TCP(Transmission Control Protocol)传输控制协议
2.UDP（User Datagram Protocol）用户数据报协议
一、TCP和UDP协议
1.TCP/IP协议族的传输层协议
1.1TCP(Transmission Control Protocol)传输控制协议
面向连接的、可靠的、基于字节流的传输层通信协议。
是供可靠的数据传输服务，确保数据无差错、不丢失、不重复、按顺序传输。
是供全双工服务，允许数据在同一时间双向传输。
TCP连接是点对点的，一条TCP连接只能连接两个端点。
TCP报文段是TCP传输数据的单元，封装在IP数据报中。
TCP报文段包含源端口、目标端口、序列号、确认号、数据偏移/首部长度、控制位(如URG、ACK.SH、RST等)等字段。
序列号用于表示本报文段所发送数据的第一个字节的编号，确保数据的顺序传输。
确认号用于表示接收方期望收到发送方下一个报文段的第一个字节数据的编号，用于确认数据传输的状态。
1.2TCP报文段
源端口号：发送方进程的端口号。
目标端口号：接收端进程的端口号。接收端收到数据段后，根据这个端口号来确定把数据送给哪个应用程序的进程。
序号：发送端为每个字节进行编号，便于接收端正确重组。
注：当TCP从进程接收数据字节时，把它们分片成数据段存储在发送缓存中，并对每一个字节进行编号。当数据到达目的地后，接收端会按照这个序号把数据重新排列，保证数据的正确性。
确认号：对发送端的确认信息。
注：接收端响应消息时将会用它来告诉发送端这个序号之前的数据段都已经收到，如确认号是x，就是表示前X-1个数据段都已经收到。
首部长度：用它可以确定TCP首部数据结构的字节长度。一般情况下TCP首部是20字节，但首部长度最大可以扩展为60字节。
控制位：
URG：紧急位。紧急指针有效位。
ACK:：确认位。只有当ACK=1时，确认序列号字段才有效:当ACK=0时，确认号字段无效。
PSH：急迫位。标志位为1时，要求接收方尽快将数据段送达应用层。
RST：重置位。当RST值为1时，通知重新建立TCP连接。
SYN：同步(连接)位。同步序号位，TCP需要建立连接时将这个值设为1。
FIN：断开位。当TCP完成数据传输需要断开连接时，提出断开连接的一方将这个值设为1.
窗口大小：说明本地可接收数据段的数目。这个值的大小是可变的，当网络通畅时接收端响应消息会将这个窗口值变大以加快传输速度，当网络不稳定时减小这个值可保证网络数据的可靠传输，TCP中的流量控制机制就是依靠变化窗口的大小实现的。
注：比如下载速度从一开始的几KB逐渐提升到几MB的过程。
校验和：用来做差错控制。字段检验的范围包括首部和数据这两部分。数据段在发送时和到达目的地时会进行校验和计算，若这两次的校验和一致，则说明数据基本是正确的，否则将认为该数据已被破坏，接收端将丢弃该数据。
紧急指针：和URG配合使用，当URG=1时有效。
选项：在TCP首部可以有多达40字节的可选信息。
例如，最大报文段长度MSS (Maximum Segment Size)。 MSS告诉对方
TCP:“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。”
1.3常用的TCP端口号及其功能
| 端口 | 协议 | 说明 |
| 21 | FTP | 文件传输协议 |
| 22 | SSH | 安全shell服务 |
| 23 | Telnet | 远程登录服务 |
| 25 | SMTP | 简单邮件传输协议 |
| 53 | DNS | 域名服务 |
| 80 | HTTP | 超文本传输协议 |
| 110 | POP3 | 邮局协议第3版本 |
| 443 | HTTPS | 安全超文本传输协议 |
| 3306 | MySQL | 数据库 |
2.UDP（User Datagram Protocol）用户数据报协议
无连接的传输协议，主要用于支持在较可靠的链路上的数据传输，或用于对延迟较敏感的应用。
不提供像TCP那样的可靠传输服务，但传输速度较快。
2.1UDP报文的首部格式
2.2常用的UDP端口号及其功能
| 端口 | 协议 | 说明 |
| 67 | DHCP | 动态主机配置协议 |
| 69 | TFTP | 简单文件传输协议 |
| 111 | RPC | 远程调用协议 |
| 123 | NTP | 网络时间协议 |
| 161 | SNMP | 简单网络管理协议 |
二、TCP建立连接三次握手
TCP是面向连接的，就是说每次发送数据之前都要和对方建立一条可靠的连接，这个建立连接的过程分为3个步骤，就叫做三次握手
①当客户端向服务器发送请求连接的报文时：
Seq序列号=x（x为随机）
SYN=1（表示发送连接请求）
②服务器端收到客户端发来的请求报文后，同意建立连接，则向客户端发送确认报文：
Seq序列号=y（这时服务器也会产生一个序列号y，和客户端的序号不相关）
Ack确认号=x+1（Seq序列号x+1，表示确认收到了客户端的请求）
ACK=1（表示这是条确认请求）
SYN=1（同时也发送一个建立连接的请求）
③客户端进程收到服务端进程的确认后，还要向服务端给出确认，然后连接成功建立：
Seq序列号=x+1（这时客户端的序号为1）
Ack确认号=y+1（表示确认收到了服务器的连接请求）
ACK=1（表示这是确认报文）
举一个简单的例子来说明
假设小明（客户端）想要给小红（服务器）发送一封信（数据）。但是他们之间并不认识，也不确定对方是否准备好接收信件，所以需要通过一个可靠的过程来建立连接。这就是TCP三次握手的作用。
第一次握手：小明说“你好，小红，我准备好了，可以开始通信吗?"
动作：小明（客户端）向小红（服务器）发送一个SYN（同步）包，表示他准备好建立连接了。这个SYN包中还包含了一个序列号（我们假设是100），用于标识小明将要发送的数据的第一个字节。
状态：小明进入SYN_SENT状态，等待小红的回应。
第二次握手：小红回应“你好，小明，我收到了，我也准备好了，可以开始通信了。”
动作：小红（服务器）收到小明的SYN包后，她回应一个SYN+ACK（同步+确认）包。这个包中包含了一个确认号(ACK=101，即小明的序列号加1)，表示她收到了小明的请求，并且她也准备好
了。同时，这个包中还包含了一个小红自己的序列号（我们假设是200），用于标识小红将要发送的数据的第一个字节。
状态：小红进入SYN_RECV状态，等待小明的最终确认。
第三次握手：小明说“好的，小红我收到了你的回应，我们可以开始通信了。”
动作：小明收到小红的SYN+ACK包后，他发送个ACK（确认）包给小红，表示他收到了小红的回
应，并且他也准备好了。这个ACK包的确认号设置为小红的序列号加1（ACK=201）。
状态：小明和小红都进入ESTABLISHED（已建立连接）状态，表示他们之间的连接已经建立，可以开始发送数据了。
三、TCP断开连接的四次挥手
讲解四次挥手的过程
第一次挥手：Client发送Fin + Acknowledgement 给Server端，表示自己要断开连接，这个时候Client端已经没有数据要发送了。
第二次挥手：Server接收到Client发送的断开请求连接，那么这个时候Server需要发送一个Acknowledgement=1用于确定客户请求断开的信息成功接收了；有时候这个过程也会和第三次握手进行合并，就像上面展示的一样。
第三次挥手：Server如果所有的数据已经接收完毕，这个时候就会发送一个FIN=1，而Acknowledgement=0用于表示Server端已经没有数据要发送了，需要关闭连接。
第四次挥手：Client端需要发送一个Acknowledgement=1表示这个Client接收到了Server的关闭请求信息，这样一来双方的就都关闭了
举一个简单的例子来说明
初始状态
假设小明（客户端）和小红（服务器）已经通过TCP三次握手建立了连接，并完成了数据的传输。
第一次挥手：小明说“我发送完了，准备关闭连接”
动作：小明决定关闭连接，于是他向小红发送一个FIN(结束)报文段，并指定一个序列号seq=X(X
是之前传输的最后一个字节的序列号加1)。
状态：小明进入FIN_WAIT 1状态，等待小红的回应。
第二次挥手：小红回应“我收到了你的关闭请求”
动作：小红收到小明的FIN报文段后，她发回一个ACK报文段，确认序号为小明的seq=X加1(即
ACK=X+1)。
状态：小红进入CLOSE_WAIT状态，表示小红已经知道小明准备关闭连接，但小红可能还有数据需要发送给小明。
客户端(小明)：收到小红的ACK后，小明进入FIN_WAIT 2状态，等待小红的关闭连接请求。
第三次挥手：小红说“我也发送完了，准备关闭连接”
动作：当小红完成数据传输后，她也向小明发送个FIN报文段，并指定一个序列号Seq=Y(Y是小红
之前传输的最后一个字节的序列号加1)。
状态：小红进入LAST_ACK状态，等待小明的最终确认。
第四次挥手：小明回应“我收到了你的关闭请求，连接已关闭”
动作：小明收到小红的FN报文段后，他发回一个ACK报文段，确认序号为小红的Seq=Y+1(即
ACK=Y+1)，表示他已经收到并同意了小红的关闭连接请求。
状态：小明等待一段时间后(通常是2MSL，即两倍的最大报文段寿命)，确保小红收到了他的ACK
报文段，然后小明进入CLOSED状态，连接完全关闭。
服务器(小红)：收到小明的ACK后，小红也进入CLOSED状态，连接完全关闭。
扫一扫
1370
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
