TCP协议 握手与挥手

应用层协议目的是了解指定协议的实现便于我们以后使用
传输层:负责应用程序之间的数据传输—TCP/UDP
了解协议的实现,体会协议的特性,理解对于上层程序编程的影响

UDP:
协议实现:
16源端-对端端口:用于描述识别通信两端进程
16位数据包长度:能够存储最大数字65535—udp报文总大小最大不能超过64K
16位校验和:采用二进制反码求和算法—校验接收方接收到的数据与发送方发送的数据是否一致。
协议特性:
无连接 :通信是不需要建立连接,只要知道对方地址就可以直接发送数据
不可靠:不保证数据安全、有序到达对端。
面向数据报:无连接的,不可靠的,无序的,有最大长度限制的传输方式
Udp传输时,sendto发送的数据会被放到发送缓冲区,而udp协议并不会等待,而是直接对数据封装头部,进行发送。
2.udp传输时,收到的数据会被放到接收缓冲区中,而udp保证数据是整条交付,不会出现半条或多条交付
编程影响:

  1. 不保证安全到达:需要在应用层使用tcp所使用的一些机制实现
  2. 不保证有序到达:需要在应用层进行包序管理
  3. Udp报文有最大长度限制:报文最大铲毒小于64K,因此发送大块数据的时候,需在应用层进行数据分包进行发送
  4. Udp实现的是整条交付:因此接收方必须定义的缓冲区足够大,能够一次性取出一条数据。

TCP协议:
协议实现:
协议特性:面向连接,可靠传输,面向字节流
面向连接:连接管理+状态管理

  1. 为什么握手是三次,而挥手是四次?
    两次不安全,四次没必要
    Tcp是一个全双工通信,两端都必须确认对方是否具有数据收发的能力
    Fin包只能表示对方不再发送数据了,不代表对方不再接收数据,因此有可能被动关闭方还会继续发送数据,因此这种情况下就不能直接发送fin包,而是等待上层用户不再发送数据了,调用close或者shutdown才会发送fin
    因此被动关闭方的ack和fin并不是一起发送的
  2. 三次握手失败了,两端是如何处理的?
    服务端回复ack+syn后,如果超时得不到ack回复,则会发送rst重置连接报文,然后释放新建套接字。
  3. TIEM_WAIT有什么用?
    TIME_WAIT是主动关闭方在进行断开连接过程中进行最后一次ack回复后进入的状态。
    如果主动关闭防回复最后一次ack后直接释放资源,就有可能在新的客户端中使用原来的这个地址信息,而如果上次ack丢失的情况下会重传fin,则新客户端收到重传的fin对新连接造成影响,以及发送syn也会受到影响。

Time_wait更多地是为了保护客户端启动不会使用钢管逼的套接字地址信息,而受到上个套接字的通信遗留问题影响

Time_wait等待2个msl时间之后,释放资源,等待两个msl是为了保证能够对重传的fin进行处理,以及保证本次通信的所有数据都消失在网络中不会对新的连接造成影响。

  1. 一台主机上出现了大量的time_wait是什么原因?如何解决?
    Time_wait是套接字主动关闭连接,最终所进入的状态,因此一台主机出现大量time_wait意味着大量的主动关闭了套接字
    解决:
  2. 减少time_wait等待时间
  3. 使用套接字选项:地址复用
    Int setsockopt(int fd,int level,int optname,void* optval,int optlen)
    Level:SOL_SOCKET
    Optname:SO_REUSEADDR—地址重用
  4. 一台主机上出现了大量的CLOSE_WAIT是什么原因?如何解决?
    Close_wait是被动关闭方,在收到fin包进行ack回复之后所进入的状态
    这个状态是一个等待上层用户调用close/shutdown(wr)后发送fin包的一个状态
    如果主机上出现了大量的close_wait的连接,那么意味着可能在代码中我们没有关闭套接字。
    解决:
    使用close/shutdown(wr)关闭套接字
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值