TCP 3次握手 4次挥手

在TCP/IP协议中，TCP 协议提供可靠的连接服务，连接是通过三次握手进行初始化的。

（1）第一次握手：Client将同步标志位SYN设置为1，随机生成一个序列号x，并将数据包发送给Server。此时Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手：Server接收到数据包之后，由SYN=1得知这是Client请求建立连接。Server将同步标志位SYN设置为1，将确认标志位ACK设置为1，ack = x+1，随机生成一个序列号y，并将数据包发送给Client确认请求。此时Server进入SYN_RCVD状态。（半连接列队）

（3）第三次握手：Client接收到数据包后，确认ack是否为x+1，如果是则将确认标志位ACK设置为1，ack=y+1，发送给Server。此时Client状态为ESTABLISHED。Server接收到数据包之后检查ack是否为y+1，如果是则成功建立连接，Serve状态进入ESTABLISHED，完成三次握手。（全连接列队）

ISN：即Initial Sequence Number（初始序列号），在三次握手的过程当中，双方会用过SYN报文来交换彼此的 ISN。

ISN 并不是一个固定的值，而是每 4 ms 加一，溢出则回到 0，这个算法使得猜测 ISN 变得很困难。那为什么要这么做？

如果 ISN 被攻击者预测到，要知道源 IP 和源端口号都是很容易伪造的，当攻击者猜测 ISN 之后，直接伪造一个 RST 后，就可以强制连接关闭的，这是非常危险的。

而动态增长的 ISN 大大提高了猜测 ISN 的难度。

为什么需要三次握手呢？

---

• 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

比如：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但是server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了，由于client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的运输连接已经建立，并一直等待client发来数据。所以没有采用“三次握手”，这种情况下server的很多资源就白白浪费掉了。

四次挥手

=======================================================================

（1）第一次挥手：Client向Server发送FIN标志，用于关闭Client到Server的数据传送，并发送序列号a，进入FIN_WAIT_1状态。这表示Client告诉Server我已经没有数据要发给你了。

（2）第二次挥手：Server接收到FIN标志后，发送一个ack=a+1，告知Client它已经接收到了关闭请求，进入CLOSE_WAIT状态。Clinet接收到回应后进入FIN_WAIT_2状态。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**