TCP/UDP常见问题

TCP
面向连接
一个连接只能是点对点(端对端、一对一)的连接
提供可靠交付
全双工通信
面向字节流的(发送的是TCP数据报,但是是以字节序列的形式流入或流出的过程)
TCP不管应用程序进程一次吧多少报文数据发送到TCP发送缓冲区中,而是根据接收方给出的窗口值和当前网络拥塞程度来决定一个报文段应包含多少个字节
TCP连接的端点是套接字:IP地址:端口(同一个端口会被不同的进程复用)
首部20字节

UDP
无连接
尽最大努力交付
面向报文段(太长:IP层分割、太短:IP层效率低)
没有拥塞控制
UDP支持一对一,一对多,多对一,多对多连接
UDP首部开销小,只有8字节

三次握手
建立一个连接需要三次握手
第一次握手:客户端给服务端发送一个SYN报文,并指明客户端的初始化序列号ISN。此时客户端处于SYN_SENT状态
第二次握手:服务器收到客户端的SYN报文以后,会以自己的SYN报文作为应答,并且也是指定了自己的初始化序列号ISN(s)。同时会把客户端的的ISN+1作为作为ack的值,表示自己已经收到了客户端的SYN,此时服务器处于SYN_SCVD的状态
第三次握手:客户端收到SYN报文后,会发送一个ACK报文,也是一样把服务器的ISN+1的值作为ACK的值,表示已经收到了服务器端的SYN报文。此时客户端处于ESTABLISHED状态,服务器在收到ACK报文后也处于ESTABLISHED状态,此时双方已经建立起了连接

半连接队列:服务器第一次接收到客户端的SYN后,就会处于SYN_RCVD,此时双方还没有完全建立其连接,服务器会把这种状态下的请求连接放到一个队列中,称之为半连接队列。
全连接队列:已经完成三次握手,建立起来的队列就会放在全连接队列当中。如果队列满了就会出现丢包现象。

ISN是固定的吗?
三次握手的其中一个重要功能就是客户端和服务器交换ISN,以便让对方知道接下来接收数据的时候如何按照序列号组装数据。如果ISN是固定的,攻击者很容易才出后续的确认号,因此ISN是动态生成的。

三次握手的过程中可以携带数据吗?
只有第三次握手可以携带数据,一,二,次握手都不可以。第一次握手不可以携带数据其中一个简单的原因就是会让服务器更容易收到攻击。

SYN攻击:
服务器的资源分配是在二次握手时候分配的,客户端的资源是在完成三次握手时候分配的。所以服务器容易收到SYN泛洪攻击,就是SYN攻击就是Client在段时间内伪造大量不存在IP地址,向服务端不断发送SYN包,服务端不断回复确认包,等待Client确认,因为客户端的IP不存在,因此server需要不断重发到超时。

四次挥手:
终止一个连接需要四次挥手
刚开始服务器和客户端都处于ESTABLISHED状态。
第一次挥手:客户端会发送一个FIN报文,报文中会指定一个序列号,此时客户端处于一个FIN_WAIT1状态。即发出连接释放报文段,并停止发送数据,主动关闭TCP连接,进入FIN_WAIT1状态,等待服务的确认。
第二次挥手: 服务端收到FIN之后,会发送ACK报文,并将客户端的序列号+1作为ACK的报文的序列号值,表示已经收到客户端的报文了,此时服务端处于CLOSE_WAIT状态。
第三次挥手:如果服务段也想断开连接了,和客户端第一次挥手一样,也会发送一个FIN报文,且指定一个序列号。此时服务端处于LAST_ACK状态。
第四次挥手:客户端收到FIN后,一样发送一个ACK 作为报文作为应答,且把服务器端的序列号值+1作为ACK的值,此时客户端处于TIME_WAIT状态。需要过一阵子以确保服务端收到自己的ACK报文后才会处于CLOSED状态,服务端收到ACK报文后,就处于CLOSED状态了。

2MSL等待状态也就是TIME_WAIT状态

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值