起因
之前自己学习的时候，碰到一些与计算机网络相关的问题。有侧重于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 地址？