cover

起因

之前自己学习的时候,碰到一些与计算机网络相关的问题。有侧重于HTTP的,也有侧重于TCP/IP等偏底层知识的。 今天对着阿里的《技术之瞳》这本书,准备系统学习一下计算机科学相关的知识。而书中的重点,就是TCP/IP。

TCP/IP 三次握手和四次挥手

首先要说的,就是最经典的问题之一,TCP/IP 三次握手和四次挥手。 具体可以看图,内容应该也很直白。

自己在学习过程中,产生的疑点在于三次挥手中的第三次握手。 也就是发送方发送ACK信号这一条。 在自己的理解中,既然已经确认了对方确认了自己的请求,那么自己再发送ACK信号是否是多余的?

后续再继续查阅相关文档时候发现,并不是自己想的那样,《图解TCP/IP》这本书简化了细节但有些时候是也不利于自己的理解。

第一次握手(SYN=1, seq=x): 客户端发送一个 TCP的 SYN 标志位置1的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。 发送完毕后,客户端进入 SYN_SEND 状态。

第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1): 服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号,放到Seq 域里,同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1,即X+1。 发送完毕后,服务器端进入 SYN_RCVD 状态。

第三次握手(ACK=1,ACKnum=y+1) 客户端再次发送确认包(ACK),SYN标志位为0,ACK标志位为1,并且把服务器发来 ACK的序号字段+1,放在确定字段中发送给对方,并且在数据段放写ISN 发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态,TCP握手结束。

引用自:TCP三次握手四次挥手

是的,《图解TCP/IP》这本书简化了客户端进入 XXX 状态这一点,所以看得时候是有些云里雾里的。

具体则是:

为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。 “已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。” 引用自:简析TCP的三次握手与四次分手

确定唯一目标

在发送数据时,如何确定唯一的发送目标。 之前自己想的是ip地址+MAC地址,后续看书时候发现并不是。 MAC地址很多时候只是充当了下一跳的作用,而非唯一地址。

而确定唯一目标的关键,则在于IP+端口号。

有了 IP 地址,为什么还要用 MAC 地址?

这个是在看ARP协议时候,产生的问题。 后面发现是因为历史遗留与需要唯一识别的原因。 具体的内容可以看:有了 IP 地址,为什么还要用 MAC 地址?

扫描二维码,分享此文章

Lxxyx's Picture
Lxxyx