目录
TCP协议
- TCP是面向连接的、可靠的进程到进程通信的协议
- TCP提供全双工服务,即数据可在同一时间双向传输
TCP报文段
源端口号:发送方进程的端口号。
目标端口号:接收端进程的端口号。接收端收到数据段后,根据这个端口号来确定把数据送给哪个应用程序的进程。
序号:发送端为每个字节进行编号,便于接收端正确重组。
当TCP从进程接收数据字节时,把它们存储在发送缓存中,并对每一个字节进行编号。当数据到达目的地后,接收端会按照这个序号把数据重新排列,保证数据的正确性。从而保证数据的安全性。
确认号:对发送端的确认信息。
接收端响应消息时将用会它来告诉发送端这个序号之前的数据段都已经收到,如确认号是X,就是表示前X-1个数据段都已经收到。从而保证数据的可靠性。
首部长度:用它可以确定首部数据结构的字节长度。一般情况下TCP首部是20字节,但首部长度最大可以扩展为60字节。
窗口大小:说明本地可接收数据段的数目。这个值的大小是可变的,当网络通畅时接收端响应消息会将这个窗口值变大以加快传输速度,当网络不稳定时减小这个值可保证网络数据的可靠传输,TCP中的流量控制机制就是依靠变化窗口的大小实现的。
比如下载速度从一开始的几KB 逐渐提升到几M 的过程。
控制位:
URG:紧急位。紧急指针有效位。
ACK:确认位。只有当 ACK=1 时,确认序列号字段才有效;当 ACK=0 时,确认号字段无效。
PSH:急迫位。标志位为 1 时,要求接收方尽快将数据段送达应用层。
RST:重置位。当 RST 值为 1 时,通知重新建立 TCP连接。
SYN:同步/连接位。同步序号位,TCP需要建立连接时将这个值设为 1。
FIN:断开位。当 TCP 完成数据传输需要断开连接时,提出断开连接的一方将这个值设为 1。
校验和:用来做差错控制。在发送TCP数据段时,由发送端计算校验和,当到达目的地时又进行一次校验和计算。若这两次的校验和一致,则说明数据基本是正确的,否则将认为该数据已被破坏,接收端将丢弃该数据。
紧急指针:和 URG配合使用,当 URG=1 时有效。
选项:在 TCP首部可以有多达 40 字节的可选信息。
TCP三次握手
第一次握手: 客户端向服务器发送 SYN 报文 (SEQ=x,SYN=1),并进入 SYN_SENT 状态,等待服务器确认
第二次握手: 实际上是分两部分来完成的,即 SYN+ACK (请求和确认) 报文
服务器收到了客户端的请求,向客户端回复一个确认信息 (ack=x+1)
服务器再向客户端发送一个 SYN 包 (SEQ=y)建立连接的请求,此时服务器进入 SYN_RECV 状态
第三次握手: 客户端收到服务器的回复 (SYN+ACK 报文0);此时,客户端也要向服务器发送确认包 (ACK);此包发送完毕客户端和服务器进入 ESTABLISHED 状态,完成 3 次握手
第一次握手: 刚开始,A 不知道自己和 B 手机的听筒和话筒是否正常,所以 A说"喂,你能听到吗?"
第二次握手: B 听到后,说明 A 的话筒和 B 的听筒正常,但 B 还需进一步检查自己的话筒和 A 的听筒是否正常;同时 B 把 A 话筒正常和自己听筒正常的消息传递给 A;于是 B “我能听到,你呢?”
第三次握手: A 收到 B 的消息后,就证明了 A 听筒正常,B 话筒正常
以上三次握手就保证了 A、B 的听筒和话筒都正常,也就保证了通话的正常,这就类似于网络建立连接时的三次握手
TCP四次挥手
(1)第一次挥手:主动断开方(可以是客户端,也可以是服务器端),向对方发送一个FIN结束请求报文,此报文的FIN位被设置为1,并且正确设置Sequence
Number(序列号)和Acknowledgment
Number(确认号)。发送完成后,主动断开方进入FIN_WAIT_1状态,这表示主动断开方没有业务数据要发送给对方,准备关闭SOCKET连接了。
(2)第二次挥手:正常情况下,在收到了主动断开方发送的FIN断开请求报文后,被动断开方会发送一个ACK响应报文,报文的Acknowledgment
Number(确认号)值为断开请求报文的Sequence Number
(序列号)加1,该ACK确认报文的含义是:“我同意你的连接断开请求”。之后,被动断开方就进入了CLOSE-WAIT(关闭等待)状态,TCP协议服务会通知高层的应用进程,对方向本地方向的连接已经关闭,对方已经没有数据要发送了,若本地还要发送数据给对方,对方依然会接受。被动断开方的CLOSE-WAIT(关闭等待)还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
主动断开方在收到了ACK报文后,由FIN_WAIT_1转换成FIN_WAIT_2状态。
(3)第三次挥手:在发送完成ACK报文后,被动断开方还可以继续完成业务数据的发送,待剩余数据发送完成后,或者CLOSE-WAIT(关闭等待)截止后,被动断开方会向主动断开方发送一个FIN+ACK结束响应报文,表示被动断开方的数据都发送完了,然后,被动断开方进入LAST_ACK状态。
(4)第四次挥手:主动断开方收在到FIN+ACK断开响应报文后,还需要进行最后的确认,向被动断开方发送一个ACK确认报文,然后,自己就进入TIME_WAIT状态,等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方,在等待完成2MSL的时间后,如果期间没有收到其他报文,则证明对方已正常关闭,主动断开方的连接最终关闭。
被动断开方在收到主动断开方的最后的ACK报文以后,最终关闭了连接,自己啥也不管了。
TCP常用端口及功能
端口 | 协议 | 说明 |
21 | FTP | FTP服务器所开放的控制端口 |
23 | TELNET | 用于远程登录,可以远程控制管理目标计算机 |
80 | HTTP | 超文本传输协议 |
443 | HTTPS | 用SSL/TLS对数据进行加密和解密,Http进行传输 |
25 | SMTP | SMTP服务器开放的端口,用于发送邮件 |
110 | POP3 | 用于邮件的接收 |
UDP协议
- 无连接、不可靠的传输协议
- 花费的开销小
UDPB报文段
- UDP长度:用来指出UDP的总长度,为首部加上数据
- 校验和;用来完成对UDP数据的差错校验,它是UDP协议提供的唯一的可靠机制
UDP常用端口号及功能
端口 | 协议 | 说明 |
69 | TFTP | 简单传输协议 |
111 | RPC | 远程过程调用 |
123 | NTP | 网络时间协议 |
161 | SNMP | 简单网络管理协议 |
总结
TCP | UDP | |
可靠性 | 可靠 | 不可靠 |
连接性 | 面向连接 | 无连接 |
报文 | 面向字节流 | 面向报文(保留报文边界) |
效率 | 传输效率低 | 传输效率高 |
双工性 | 全双工 | 一对一 一对多 多对一 多对多 |
流量控制 | 有(滑动窗口) | 无 |
拥塞控制 | 有(满开始 拥塞避免 快重传 快恢复) | 无 |
ps:补充
为什么是三次??
主要是为了建立可靠的通信通道,保证客户端与服务端同时具备发送、接收数据的能力
四次握手可以吗?
可以,但没必要
四次握手可以验证双方的发送接收能力正常,但是这样做效率比较低
四次挥手,三次挥完行不行?
通常情况下不行,若触发了延时应答机制,就可以三次挥完
"不行",即:上述的 ② ACK ③FIN为什么没有合并在一起??
因为中间两次操作的时机不一样
ACK 是收到 FIN 之后立刻由内核返回的数据报,FIN 是应用程序处理完接受缓冲区的数据之后,调用的 close 方法触发的
为什么四次?
因为要确保客户端和服务端的数据能够完成传输