TCP浅析(1)

TCP:

TCP(传输控制协议)是面向连接,可靠传输,面向字节流的传输层协议。

  1. 面向连接:通过三次握手建立连接,四次挥手释放连接,以及状态的连接管理实现面向连接。tcp是一个有状态的协议。
  2. 可靠传输:保证数据有序并且可靠的到达对端;
  3. 面向字节流:可靠的,有序的,双向的,基于连接的字节流传输(不限制上层发送/接收的数据大小)

协议格式:在这里插入图片描述

  • 16位源端口 / 目的端口:负责实现应用程序之间的数据传输。
  • 32位序号 / 确认序号:用于实现tcp在传输层的包序管理,保证tcp有序的交付数据;
  • 4位首部长度:以4个字节为单位,4位保存的最大数字是15,因此tcp报头最大长度是60个字节。
  • 6位标志:
    URG 紧急指针标志 ACK 确认回复标志
    PSH 提示立即接收位 RST 重置连接位
    SYN 连接建立请求位 FIN 断开连接请求位
  • 16位窗口大小:滑动窗口机制,实现流量控制,告诉对端所能发送的最大数据量。
  • 校验和:二进制反码求和,校验数据一致性;
  • 紧急指针:知名哪些数据是紧急数据;
  • 选项数据:三次握手时,协商MSS大小的数据。

常问问题

  1. 握手为什么不是两次 / 四次 而是三次? 两次不安全,四次没必要。
    TCP是双向通信,需要双方都要确保对方在线,具有数据收发的能力,假设客户端发送SYN请求后直接退出了;若只是两次就建立连接服务端发送数据就会丢失,因此服务端收到请求回复之后还需要确保客户端也具有数据收发的能力,因此客户端还需要再发送一次ACK。

  2. 挥手为什么是四次而不是三次? FIN表示的并非断开连接,可能是对方不再继续写数据了。
    TCP向对方发送FIN不仅仅有close直接不读也不写,也可能是因为关闭了写端因此发送FIN;
    意味着这一端虽然不再发送数据,但是还有可能要接收数据;
    因此操作系统收到FIN,不能直接断开,因为接收FIN包的这一方可能还要发送数据过去;
    因此接收方的ACK和FIN包就不能一起发送,只有接收方确认对端不再发送数据才会发送FIN包。

  3. FIN包发送方为什么发送最后一个ACK之后并没有closed状态释放资源,而是进入TIME_WAIT状态等待一段时间??
    假设若是没有TIME_WAIT直接进入closed释放资源有可能造成的危险:
    若客户端又立即使用相同的地址信息启动了客户端,什么都还没干突然收到一个FIN,则会对新连接造成影响;
    若客户端又立即使用相同的地址信息启动了客户端,向服务端发送SYN,而服务端这时候LAST_ACK,收到SYN则会认为状态错误,向客户端发送RST重置连接报文,要求对方重新建立连接。因此主动关闭方,发送最后一个ACK之后,需要等待一段时间,处理有可能重传的FIN包。等待这段时间通常是两个MSL时间(MSL报文最大生存周期)
    两个MSL指的是重传的FIN 以及响应的ACK两个报文的生存周期,目的在于要求本次来连接的所有数据都消失在网络中,不再对后续新连接造成影响。

  4. 若三次握手失败了,服务器如何处理?
    客户端发送的SYN直接就没有到达服务器,服务端不知道有这个请求,因此没什么处理。
    客户端发送了SYN后服务端收到并进行了SYN+ACK响应,但是没有收到ACK。
    服务端等待最后一个ACK超时后,则会给客户端发送RST重置连接报文,要求对方重新发起连接请求,释放当前新建的这个套接字,而并非重传SYN+ACK。

  5. 服务器上出现大量的CLOSE_WAIT是什么原因?
    CLOSE_WAIT:收到FIN进行回复后的状态,等待程序调用close /shutdown(wr)表示程序中可能对大量的套接字连接断开后,没有调用close关闭,释放资源。(这是一种代码中的操作)

  6. 服务器中出现大量的TIME_WAIT是什么原因?
    TIME_WAIT:主动关闭后,发送最后一个ACK之前的状态;意味着服务器上大量的主动关闭了连接,通常在爬虫服务器上。(解决方法:开启地址重用 / 设置MSL时间)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值