TCP/UDP备忘
ISO模型与TCP/IP模型
ISO 七层模型 | TCP/IP 四层模型 | |
应用层 | HTTP HTTPS DNS SMTP SNMP FTP Telnet SSH | 应用层 |
表示层 | ||
会话层 | SSH RPC ASP BSD Sockets | |
传输层 | TCP UDP RTP SCTP SPX ATP IL | 传输层 |
网络层 | IP ICMP IGMP BGP OSPF RIP ARP RARP | 网络互连层 |
数据链路层 | Etherent HDLC WIFI FDDI PPP | 网络接口层 |
物理层 |
只运行在TCP上协议:
- HTTP、HTTPS
- FTP(文件传输协议):用于文件传输
- POP3(邮局协议):用来收取邮件
- SMTP(简单邮件传输协议):用来发送邮件
- Telnet(虚拟终端协议):通过终端登陆到网络;
- SSH(Secure Shell):用来替代安全性较差的Telnet,用于加密安全登陆;
只运行在UDP上的协议:
- DNS(域名解析协议):DNS通常基于UDP协议;
- SNMP(简单网络管理协议):用来收集和管理网络信息;
- TFTP
- VOIP
运行在TPC和UDP上的协议
- DNS (Domain Name Service,域名服务) ,用于完成地址查找,邮件转发等工作
- ECHO (Echo Protocol, 回绕协议) ,用于查错及测量应答时间
端口
传输层按照端口号寻址(数据链路层按照MAC地址寻址,网络层按照IP地址寻址);
传输层的端口号大小占16位,端口号只具有本地意义,用来标识应用层中的各个进程;
TCP首部
TCP数据(TCP首部+TCP数据)被封装在一个IP数据报中
不考虑选项字段的情况下,TCP首部大小为20字节;
Seq/Sequence number/序号:大小32位,seq序号用来标识TCP发送方发送的字节流,由发送方进行标记
- TCP用序号对字节流的每个字节进行计数,表示该报文段中的第一个数据字节;
- 序号物理上是32位的无符号数,序号到达232-1之后又从0开始;
- Ack表示发送确认一方所期望收到的下一个序号,因此ACK序号 = 上次已成功收到的数据字节序号 + 1;
检验和:大小16位,由发送方计算和存储,接收方进行验证;
选项/可选字段:最常见的可选字段时最长报文大小MSS(Maximum Segment Size),指明本段所能接收报文的最大长度;
标志位:大小6位,分别为URG、ACK、PSH、RST、SYN、FIN;
- URG(Urgent):紧急指针有效(待补充)
- ACK(Acknowledge):确认序号/Ack有效
- PSH(Push):接收方应尽快将该报文段交给应用层
- RST(Reset):重置连接;
- SYN(Synchronous):建立一个新连接时,SYN = 1,序号字段Seq表示该连接的初始序号ISN(Initial Sequence Number);
- FIN(Finish):释放一个连接,
TCP建立连接-三次握手
1. 第一次握手(Client==>>Server):Client向Server申请建立Client到Server的连接
- SYN = 1:Client向Server请求建立单向连接
- Seq = 200:Client告诉Server它将在连接中发送数据的初始序号为200
- 不携带任何应用层数据
- Client进入SYN_SENT状态
2. 第二次握手(Server==>>Client):Server收到数据包后,确认建立Client到Server的连接,同时希望建立Server到Client的连接;
- SYN = 1:Server向Client请求建立单向连接
- Seq = 500:告诉Client,Server将在连接中发送数据的初始序号为500
- ACK = 1:确认收到Client发送Seq = 200的数据包,同意建立Client到Server的单向连接
- Ack = 201:期望下次收到Seq = 201的数据包
- Server同意建立连接后,会为连接分配缓存和变量
- Server进入SYN_RCVD状态
3. 第三次握手(Client==>>Server):Client再次确认Server的确认,并且确认建立Server到Client的连接;
- Seq = 201:数据包编号
- ACK = 1:确认收到Server发送Seq = 500的数据包,同意建立Server到Client的单向连接
- Ack = 501:期望下次收到Seq = 501的数据包
- 不携带任何应用层数据
- Client同意建立连接,会为连接分配缓存和变量
- Client和Server都进入ESTABLISHED状态,完成三次挥手
★ TCP为何采用三次握手建立连接,二次握手可以吗?
答:
TCP采取三次握手建立连接是为了防止失效的连接请求报文段造成错误;
如果采用二次握手,当Client第一次发送的连接请求报文段由于网络延迟没有及时送达,Client误以为报文段丢失,重发一个新的连接请求报文给Server端,Server端确认后双发建立TCP连接。当延迟到达的连接请求报文到达时,Server端误以为Client再次请求建立连接,回复确认报文段,但是Client不再处理Server的回复确认报文段,导致Server一直空等,造成资源浪费,大量的连接失效请求报文会导致Server端崩溃;
TCP释放连接-四次挥手
- FIN = 1:Client申请关闭Client到Server的连接;
- ACK = 1, Ack = 500:Client回复挥手之前的报文,期望Server回复序号为500的同意报文段;
- Client进入FIN_WAIT_1状态
2. 第二次挥手:同意关闭Client到Server的连接
- Server端收到FIN后,同意关闭Client到Server的连接
- Server进入CLOSE_WAIT状态
- Client进入FIN_WAIT_2状态
- 此时TCP处于半关闭状态:Client到Server连接关闭,但是Server到Client连接仍然可用
3. 第三次挥手:申请关闭Server到Client的连接
- Server发送一个FIN,申请关闭Server到Client的连接
- Server进入LAST_ACK状态
4. 第四次挥手:同意关闭Server到Client的连接
- Client接着发送ACK给Server,同意关闭Server到Client的连接
- Client发送ACK后,Client进入TIME_WAIT状态,保持2MSL时间
- MSL(Maximum Segment Lifetime):报文段在网络上的最大生存时间,超过这个时间的报文将被丢弃;
- 当Client等待了2MSL时间后又收到FIN,证明之前发送的ACK没有送达Server(Server重发了FIN),于是Client重发ACK;
- 当Client等待了2MSL时间后没收到FIN,证明之前发送的ACK已经送达Server,Client进入CLOSED状态,完成四次挥手
- Server收到ACK后进入CLOSED状态,完成四次挥手
★ TCP为何采用四次挥手释放连接,三次挥手可以吗?
答:TCP连接是全双工连接,每个FIN报文段,都需要一次ACK报文确认。一端收到另一端发送的FIN报文段时,仅仅表示对方不再发送数据了但是还能接收数据,而且己方也未必将全部数据发送给对方,因此己方可以发送一些数据给对方后再发送FIN,或者立即发送FIN申请关闭连接,因此第二次挥手和第三次挥手是分开进行的,需要四次挥手;
TCP状态迁移图
UDP首部
UDP数据报分为UDP首部和UDP数据,其中UDP首部大小占8字节;
UDP长度字段 = UDP首部+UDP数据的字节长度 = IP数据报长度 - IP首部长度,最小值为8字节(发送一个0字节的UDP数据报);
UDP适用于系统资源有限,要求较好实时性,较小网络开销,传输速度快的场合;
TCP与UDP辨析
TCP与UDP不同
- TCP是有连接的,必须通过三次握手建立连接;而UDP是无连接的,不需要建立连接;
- TCP是可靠的传输,TCP协议通过确认和重传机制来保证数据传输的可靠性;而UDP是不可靠的传输,不保证数据准确无误到达目的地;
- TCP通过超时重传,ACK确认等机制提供可靠传输;
- TCP提供流量控制,UDP不提供流量控制;
- TCP通过接收窗口rwnd控制对端发送的流量;
- TCP提供拥塞控制机制,UDP没有拥塞控制,网络阻塞时导致网络性能下降;
- TCP是基于字节流的,将数据看做无结构的字节流进行传输,当应用程序交给TCP的数据长度太长,超过MSS时,TCP就会对数据进行分段,因此TCP的数据是无边界的;而UDP是面向报文的,无论应用程序交给UDP层多长的报文,UDP都不会对数据报进行任何拆分等处理;
TCP与UDP相同
- TCP与UDP都是全双工连接;
- TCP与UDP都可以使用IPv4或IPv6;
所有博文来自个人为知笔记,内容多为读书笔记和理解内容;