计算机网络(二)TCP和UDP协议

一、UDP协议

UDP 头部包含了以下几个数据:

  • 两个十六位的端口号,分别为源端口(可选字段)和目标端口
  • 整个数据报文的长度
  • 整个数据报文的检验和(IPv4 可选 字段),该字段用于发现头部信息和数据中的错误

协议特点

1、面向无连接

2、有单播,多播,广播的功能

UDP 支持一对一的传输方式,同样支持一对多,多对多,多对一的方式,也就是说 UDP 提供了单播,多播,广播的功能。

3、UDP是面向报文的

发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文

4、不可靠性

没有应答,没有超时重发机制,

5. 头部开销小,传输数据报文时是很高效的。

二、TCP协议

1、协议特点

1、面向连接

2、面向字节流

TCP不像UDP一样那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。

3、一对一服务

4、可靠传输

2、确认应答机制

RFC 建议了一种延迟的 ACK,也就是说,ACK 在收到数据后并不马上回复,而是延迟一段可以接受的时间,延迟一段时间的目的是看能不能和接收方要发给发送方的数据一起回去,因为 TCP 协议头中总是包含确认号的,如果能的话,就将数据一起捎带回去,这样网络利用率就提高了。延迟 ACK 就算没有数据捎带,那么如果收到了按序的两个包,那么只要对第二包做确认即可,这样也能省去一个 ACK 消耗。

3、TCP报文格式

 

  • 源端口和目的端口:各占2个字节,分别写入源端口号和目的端口号。
  • 序号:占4个字节。序号使用mod运算。TCP是面向字节流的,在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。故该字段也叫做“报文段序号”。
  • 确认序号:只有ACK=1时有效,占4个字节,是期望收到对方下一个报文段的第一个数据字节的序号。若确认序号=N,则表明:到序号N-1为止的所有数据都已正确收到。
  • 数据偏移:占4位,表示TCP报文段的首部长度。注意,“数据偏移”的单位是32位字(即以4字节长的字为计算单位)。故TCP首部的最大长度为60字节。
  • 保留:占6位,保留为今后使用,目前置为0;
  • 紧急URG:当URG=1,表明紧急指针字段有效。这时发送方TCP就把紧急数据插入到本报文段数据的最前面,而在紧急数据后面的数据仍是普通数据。
  • 确认ACK:当ACK=1时,确认字段才有效。当ACK=0时,确认号无效。TCP规定,在连接建立后所有传送的报文段都必须把ACK置1。
  • 推送PSH:接收方TCP收到PSH=1的报文段,就尽快地交付给接收应用进程,而不再等到整个缓存都填满了后再向上交付。
  • 复位RST:当RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立运输连接。
  • 同步SYN:在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文段。对方若同意建立连接,则应在响应的报文段中使SYN=1和ACK=1。故SYN置为1,就表示这是一个连接请求和连接接收报文。
  • 终止FIN:用来释放连接。当FIN=1时,表明此报文段的发送方的数据已发送完毕,并要求释放运输连接。
  • 窗口:占2个字节。窗口值作为接收方让发送方设置其发送窗口的依据。
  • 检验和:占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP数据报一样,在计算检验和时,也要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样,但要将伪首部第四个字段中的17 改为6(协议号),把第5字段中的UDP长度改为TCP长度。
  • 紧急指针:占2字节。紧急指针仅在URG=1时才有意义,它指出本报文段中的紧急数据的字节数。

4、三次握手

TCP 进行握手初始化一个连接目标是:分配资源、初始化序列号(通知 peer 对端我的初始序列号是多少),知道初始化连接的目标,握手过程可以简化为下面的四次交互:

  1. client 端首先发送一个 SYN 包告诉 Server 端我的初始序列号是 X;
  2. Server 端收到 SYN 包后回复给 client 一个 ACK 确认包,告诉 client 说我收到了;
  3. 接着 Server 端也需要告诉 client 端自己的初始序列号,于是 Server 也发送一个 SYN 包告诉 client 我的初始序列号是 Y;
  4. Client 收到后,回复 Server 一个 ACK 确认包说我知道了。
  • Server 发送 SYN 包是作为发起连接的 SYN 包,还是作为响应发起者的 SYN 包呢?怎么区分?比较容易引起混淆
  • Server 的 ACK 确认包和接下来的 SYN 包可以合成一个 SYN ACK 包一起发送的,没必要分别单独发送,这样省了一次交互同时也解决了问题[1].这样 TCP 建立一个连接,三次握手在进行最少次交互的情况下完成了 Peer 两端的资源分配和初始化序列号的交换。

第一次:客户端发送请求报文,SYN标识位是1,seq=x(序号=随机数)。客户端进入SYN_SENT状态。

第二次:服务端受到连接到syn=1的报文,知道是请求连接。服务端回复确认数据,SYN=1,ACK = 1,seq=y(序号=随机数),acknum = x+1(确认序号=x+1)。服务器端进入SYN_RCVD状态。

第三次:客户端接收到确认信息,判断ACK=1,acknum=x+1。回复确认数据,ACK=1,acknum=y+1。服务器判断ACK和acknum,连接建立完成。

 5、四次挥手

第一次:客户端发送关闭报文,FIN=1,seq=u(u是上一个数据包的序号+1)。客户端进入FIN-WAIT-1阶段,即半关闭阶段。停止发送数据。

第二次:服务端回复确认包,ACK=1,seq=v(服务端的序号),acknum=u+1,CLOSE-WAIT阶段(半关闭状态)。客户端收到从服务器端发出的TCP报文之后,进入FIN-WAIT-2阶段。

第三次:服务端经过等待之后,发送关闭报文,FIN=1,ACK=1,seq=w,acknum=u+1。进入LAST-ACK阶段。停止发送数据。

第四次:客户端接收关闭报文,进入TIME-WAIT阶段,发送确认报文,ACK=1,seq=u+1,acknum=w+1。客户端会在TIME-WAIT状态,连接不会立刻关闭,会等待一段时间后关闭。

TIME-WAIT状态作用

  • 客户端需要进入 TIME_WAIT 以便能够重发丢掉的被动关闭方 FIN 包的 ACK。
  • 防止链路上已经关闭的连接的残余数据包干扰正常的数据包,造成数据流的不正常。

 

 

 

 

 

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值