网络层--TCP/UDP协议

一、TCP/UDP协议介绍

1、UDP(User Datagram Protocol)--用户数据报协议

1.1 UDP报文格式

1.2 UDP协议的特性

2、TCP(Transmission Control Protocol )--传输控制协议

2.1 TCP报文格式

2.2 TCP协议的特性

2.3 TCP三次握手

2.4 四次挥手

三、TCP和UDP的区别

四、telnet协议--telnet协议--远程管理协议

一、TCP/UDP协议介绍

1、UDP(User Datagram Protocol)--用户数据报协议

UDP是无连接的、不可靠的面向消息的传输层协议，尽管UDP协议提供标标头和有效负载的完整性验证（通过校验和），但他不保证向上层协议提供消息传递，并且UDP层在发送后不会保留UDP消息的状态。

1.1 UDP报文格式

16位UDP长度表示整个数据报(UDP首部+UDP数据)的长度
如果校验和出错，就会直接丢弃(UDP校验首部和数据部分)

1.2 UDP协议的特性

工作在传输层

提供不可靠的网络访问

非面向连接协议

有限的错误检查

传输性能高

无数据恢复特性

2、TCP(Transmission Control Protocol )--传输控制协议

TCP是面向连接的、可靠的进程到进程通信的协议
TCP提供全双工服务，即数据可在同一时间双向传输
TCP报文段

TCP将若干个字节构成一个分组，叫报文段(Segment)。
TCP报文段封装在IP数据报中

2.1 TCP报文格式

源端口、目标端口：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个,即 65536 （0-65535）

端口号的作用：用于区别应用程序，或者说用来区别协议（只能区别应用层协议）

客户端的端口号：随机的

服务端的端口号：一般是固定的

序列号：发送端为每个字节进行编号，便于接收端正确重组
确认号：（ack））用于确认发送端的信息
首部长度：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节
控制位：描述了设备目前处于什么状态

URG（紧急位）：与紧急指针联动。表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效

ACK（确认位）：表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段

PSH（急切位）： 提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中

RST（重置位）：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段

SYN（同步位）：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段

FIN（断开位）：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段

状态位数值表示状态
SYN=1 请求建立连接
SYN=1 ACK=1 同意和你连接
FIN=1 请求断开
FIN=1 ACK=1 同意和你断开

滑动窗口大小：调节每次发送的数据包量

服务端和客户端之间会根据实际情况自动调节数据包的个数

校验和：提供额外的可靠性紧急指针：标记紧急数据在数据字段中的位置

选项部分：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节

2.2 TCP协议的特性

1.工作在传输层
2.面向连接协议
3.全双工协议
4.半关闭-- 断开
5.错误检查(校验)
6.将数据打包成段，排序(给数据排序)
7.确认机制（对面每发一个包，我会告诉对面我收到了）
8.数据恢复，重传
9. 流量控制，滑动窗口

2.3 TCP三次握手

第一次握手：客户端会主动发起请求连接报文，报文序号是随机产生的x，并且报文中的控制位SYN=1--代表请求建立连接

--此时客户端处于SYN-SENT状态

第二次握手：当服务端接收到请求连接的报文会回复一个报文，此时会产生随机序号y，生成一个确定号值为客户端请求报文的序号+1(x+1)，然后控制位 SYN=1 ACK=1 代表同意建立连接

--此时服务器处于SYN-RCVD状态

第三次握手：当客户端收到同意建立连接的报文时会回复一个确认报文会按照对方要求产生序号为x+1,在生成一个确认号值为对方报文的序号+1（y+1），最后控制位的ACK=1代表收到对方同意连接的请求，

--此时客户端处于ESTAB-LISHED状态。服务器收到 ACK 报文之后，也处于ESTAB-LISHED 状态，此时，双方已建立起了连接。

第一次、第二次握手不可以携带数据，只有第三次携带数据。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

2.4 四次挥手

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

--即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
--即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
--即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
--即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

挥手为什么需要四次？
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

三、TCP和UDP的区别

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠，不使用流量控制和拥塞控制	可靠，传输使用流量控制和拥塞控制
传输方式	面向报文	面向字节流
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用 (IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例女文件传输