企业官网建设流程全解析

上海网站建设公司网站建设,关键词搜索挖掘爱网站,市局网站建设建议,沈阳小装修公司哪家好1.TCP连接和端口 一、三次握手#xff1a;建立连接#xff08;好比打电话#xff09; 想象你要给朋友小明打电话确认一件事。 目标#xff1a;确保双方都能听和说#xff0c;连接可靠。 过程#xff1a; 第一次握手#xff08;SYN#xff09; #x1f449; 你打给…1.TCP连接和端口一、三次握手建立连接好比打电话想象你要给朋友小明打电话确认一件事。目标确保双方都能听和说连接可靠。过程第一次握手SYN你打给小明问“喂小明能听到我说话吗”你主动发起连接发送一个SYN包进入SYN_SENT状态第二次握手SYN ACK小明听到后回答“我能听到你。你能听到我吗”小明确认收到你的请求同时也发起他的连接请求发送SYNACK包进入SYN_RCVD状态关键这个动作同时完成了两件事确认你的电话 发起他的反问。第三次握手ACK你听到小明的反问后说“我能听到你”你确认小明的请求发送ACK包连接建立成功。双方进入ESTABLISHED状态为什么不是两次如果只有两次小明的反问第二次握手万一你没听到小明就以为连接好了开始说话结果你根本没准备好听会造成混乱。第三次握手就是为了**确认“双方都准备好”**这个状态。二、四次挥手断开连接好比挂电话通话结束了你们要礼貌地挂断电话。目标确保双方想说的话都说完了再彻底断开。过程第一次挥手FIN你说“我这边说完了要挂电话啦。”你主动关闭连接发送FIN包进入FIN_WAIT_1状态。代表我不会再发数据了但我还可以听。第二次挥手ACK小明立刻回应“哦我知道你说完了。”小明发送ACK包确认收到你的结束请求。你进入FIN_WAIT_2状态。注意此时小明可能还有话没说完所以连接处于半关闭状态你不说了但还可以听小明说。第三次挥手FIN小明把他的话说完后也说“我也说完了挂了吧。”小明也发送FIN包进入LAST_ACK状态。第四次挥手ACK你听到后最后回应“好的挂了拜拜。”你发送ACK包然后等待一段时间2MSL后彻底关闭。小明收到后也立即关闭。为什么需要四次因为TCP连接是全双工的就像电话线有两根一根你说话一根小明说话。挥手必须独立关闭两个方向第一次第二次关闭你 → 小明的方向。第三次第四次关闭小明 → 你的方向。中间可能有延迟所以小明需要时间把他想说的话数据说完再发起他的FIN。一张图帮你永久记忆三次握手 (建立连接) 我你听得到吗 (SYN) 你我听到了。你听得到我吗 (SYN ACK) 我我也听到了 (ACK) -- 开始通话 四次挥手 (断开连接) 我我说完了。 (FIN) 你知道了。 (ACK) 你继续说你没说完的话 你我也说完了。 (FIN) 我好的再见。 (ACK) -- 挂断电话三次握手“你喊我 → 我应你我也准备好 → 你确认” → 连接建立四次挥手“我说完 → 你确认 → 你说完 → 我确认” → 连接断开核心要点总结三次握手的本质确认“彼此都能收发”。四次挥手的本质分别关闭“两个方向的通道”确保数据完整。关键区别握手时服务端的SYN和ACK可以合并发送但挥手时服务器的ACK和FIN通常不能合并因为中间可能还有数据要发送。下次再记不住就想打电话的场景接通需要三次确认挂断需要四次礼貌告别。这样就再也不会忘了2.初始序列号ISN, Initial Sequence Number是 TCP 连接建立时通信双方各自随机生成的一个32 位起始序号用于标识该连接中第一个数据字节的编号。 通俗理解你可以把 ISN 想象成“快递单号的起点”。比如你第一次给朋友寄包裹快递公司说“你的第一件包裹单号从87654321开始。”之后每寄一个包裹单号就 1或按字节数累加。对方收到后就知道“哦这是第 1 个包裹”、“这个是不是重复寄了”、“有没有漏掉中间的”在 TCP 中每个字节的数据都有一个序列号从 ISN 开始递增。接收方靠这个序号来✅ 去重、✅ 检测丢包、✅ 按正确顺序重组数据。 为什么 ISN 要「随机生成」早期 TCP 曾用固定值比如 0 或 1作为 ISN但这样有严重安全问题❌ 问题容易被伪造/劫持连接攻击者猜到你的 ISN比如总是从 1 开始就可以伪造一个“看起来合法”的 ACK 包冒充你发送数据甚至中断连接。这叫TCP 序列号预测攻击。✅ 解决方案随机化 ISN现代系统用基于时间随机因子的算法生成 ISN例如每 4 微秒 1并加入熵。让攻击者几乎无法预测下一个连接的起始序号大幅提升安全性。 RFC 6528 建议ISN 应具有不可预测性以防止连接劫持。 ISN 在三次握手中的作用三次握手其实也是交换并确认彼此 ISN 的过程步骤发送方 → 接收方关键内容1客户端 → 服务器SYN1, seq ISN_client2服务器 → 客户端SYN1, ACK1, seq ISN_server, ack ISN_client 13客户端 → 服务器ACK1, seq ISN_client 1, ack ISN_server 1✅ 到第三次握手完成时客户端知道服务器的起始序号是ISN_server服务器知道客户端的起始序号是ISN_client双方后续发送的数据就从各自的 ISN1 开始编号 举个例子假设客户端 ISN 1000服务器 ISN 3000那么客户端发的第一个数据字节序列号是1001服务器发的第一个数据字节序列号是3001如果客户端收到一个 seq3001 的包就知道这是服务器的第一段数据如果后来又收到一个 seq3001 的包→重复了直接丢弃。如果收到 seq3003但没收到 3001 和 3002→丢包了要求重传。✅ 总结项目说明ISN 是什么TCP 连接中第一个字节的起始序列号32 位为什么需要实现可靠传输去重、防丢、保序为什么随机防止攻击者预测并伪造数据包何时确定在三次握手的前两步中交换并在第三步确认简单记ISN 数据流的“起跑线编号”随机设定确保安全和有序。希望这个解释让你彻底搞懂 ISN 3.三次握手TCP格式TCP 三次握手是建立连接的核心过程核心目的是同步序列号、确保双向通信可靠。以下是详细步骤第一种解释TCP三次握手第一步SYN客户端 → 服务器客户端发送一个SYN1标志的 TCP 报文段。随机生成一个初始序列号Client ISN假设为x。不携带应用层数据。状态变化客户端进入SYN_SENT状态。服务器处于LISTEN状态。报文格式SYN1, Seqx, Ack0第二步SYN-ACK服务器 → 客户端服务器收到 SYN 后若同意连接则回复SYN1和ACK1。随机生成自己的初始序列号Server ISN假设为y。确认号Ack x 1表示期望收到客户端的下一个序列号。状态变化服务器进入SYN_RCVD状态。报文格式SYN1, ACK1, Seqy, Ackx1第三步ACK客户端 → 服务器客户端收到 SYN-ACK 后发送ACK1。序列号Seq x 1第一步的 Seq1。确认号Ack y 1表示期望收到服务器的下一个序列号。此后可以携带应用层数据。状态变化客户端进入ESTABLISHED状态。服务器收到 ACK 后也进入ESTABLISHED状态。报文格式ACK1, Seqx1, Acky1第二种解释TCP三次握手TCP 三次握手Three-Way Handshake是 TCP 协议在建立可靠连接时的核心机制。它的目标是✅ 确认双方通信能力正常✅ 同步初始序列号ISN✅ 防止历史连接干扰✅ 避免资源浪费 前提客户端Client主动发起连接如浏览器访问网站服务器Server处于LISTEN状态等待连接第一次握手客户端 → 服务器SYN客户端动作生成一个随机的初始序列号 ISN_Client例如 1000发送 SYN 报文段SYN 1 seq ISN_Client 1000 ACK 0不置位客户端状态变化CLOSED→SYN_SENT 此时报文不含数据只用于请求连接。第二次握手服务器 → 客户端SYN ACK服务器动作收到 SYN 后分配连接资源如缓冲区、TCB 控制块生成自己的随机初始序列号 ISN_Server例如 3000回复 SYNACK 报文段SYN 1 ACK 1 seq ISN_Server 3000 ack ISN_Client 1 1001 // 确认收到了客户端的 SYN服务器状态变化LISTEN→SYN_RECEIVED⚠️ 注意这里同时完成了两件事确认客户端的 SYNack1001发送自己的 SYNseq3000第三次握手客户端 → 服务器ACK客户端动作收到 SYNACK 后验证ack 自己的 ISN 1即 1001确认有效发送纯 ACK 报文段SYN 0 ACK 1 seq ISN_Client 1 1001 // 下一个要发的数据序号 ack ISN_Server 1 3001 // 确认收到了服务器的 SYN客户端状态变化SYN_SENT→ESTABLISHED连接已建立可发数据服务器收到 ACK 后验证ack 自己的 ISN 1即 3001状态变为SYN_RECEIVED→ESTABLISHED✅ 至此双向连接正式建立双方可以开始传输数据 状态机总结步骤发送方报文标志seqack发送方状态 → 新状态1ClientSYN1000—CLOSED →SYN_SENT2ServerSYNACK30001001LISTEN →SYN_RECEIVED3ClientACK10013001SYN_SENT →ESTABLISHED隐式Server———SYN_RECEIVED →ESTABLISHED 服务器在收到第三次握手的 ACK 后才进入 ESTABLISHED。 为什么需要这三步关键作用目标如何实现双向通信确认每一方都发送过 收到过对方的包同步 ISN双方交换并确认彼此的初始序列号防历史连接旧 SYN 无法触发第三次 ACK连接不会建立防资源浪费服务器在收到第三次 ACK 前可限制半开连接数缓解 SYN Flood 举个实际抓包示例Wireshark 风格No. Time Source Destination Protocol Info 1 0.000 192.168.1.10 192.168.1.20 TCP 54321 → 80 [SYN] Seq1000 2 0.001 192.168.1.20 192.168.1.10 TCP 80 → 54321 [SYN, ACK] Seq3000 Ack1001 3 0.002 192.168.1.10 192.168.1.20 TCP 54321 → 80 [ACK] Seq1001 Ack3001之后就可以看到[PSH, ACK]开始传 HTTP 请求了。✅ 小结口诀一发 SYN二回 SYNACK三发 ACK双方 ISN 互换确认连接才算真建立这就是 TCP 三次握手的完整、严谨又可靠的设计逻辑。为什么需要三次握手防止历史连接初始化主要原因若客户端发送的旧 SYN 报文延迟到达服务器会回复 SYN-ACK客户端根据当前上下文判断这是旧连接则发送RST中止避免错误建立连接。使用「三次握手」如何避免这个问题旧 SYNseq100到达 Server→ Server 回复 SYNACK, seq300, ack101第二步Client 收到后发现“我现在的 ISN 是 2000根本没发过 seq100 的 SYN”所以它知道这是历史连接不会发第三次 ACK。有些实现会回一个 RST 表示拒绝Server 等不到第三次 ACK→ 超时后自动释放资源连接 never established。同步双方初始序列号序列号是 TCP 可靠传输的核心保证数据顺序、去重。握手过程中双方互相确认对方的初始序列号并同步至可靠状态。避免资源浪费二次握手时服务器收到 SYN 即认为连接建立若客户端不响应 ACK服务器会维持无效连接导致资源浪费。关键细节序列号随机化防止被猜测而伪造报文安全考虑。半连接队列服务器在SYN_RCVD状态时将连接放入半连接队列完成握手后移至全连接队列。SYN Flood 攻击攻击者发送大量 SYN 但不完成握手耗尽服务器半连接队列资源。防御方式包括SYN Cookie等。握手过程图示客户端 服务器 | | |---- SYN (Seqx)----| |-- SYN-ACK (Seqy, Ackx1) --| |---- ACK (Acky1) ----| | | 连接建立 连接建立通过三次握手双方确认了通信能力和初始序列号为可靠数据传输奠定基础。4. tcp 断开 四次挥手TCP 四次挥手是有序终止双向连接的过程。由于 TCP 连接是全双工的每个方向必须单独关闭。挥手过程详解第一步FIN主动关闭方 → 被动关闭方主动关闭方假设为客户端发送FIN1的报文段。序列号为当前已传输数据的最后一个字节序号 1假设为u。进入FIN_WAIT_1状态表示不再发送数据但还能接收数据。报文格式FIN1, Sequ第二步ACK被动关闭方 → 主动关闭方被动关闭方服务器收到 FIN 后立即回复ACK1。确认号Ack u 1表示已收到 FIN。服务器进入CLOSE_WAIT状态此时仍可向客户端发送剩余数据。客户端收到 ACK 后进入FIN_WAIT_2状态等待服务器的 FIN。报文格式ACK1, Seqv, Acku1第三步FIN被动关闭方 → 主动关闭方服务器完成数据发送后发送自己的FIN1报文段。序列号假设为w取决于第二步后发送的数据量。确认号仍为Ack u 1可携带或不携带 ACK通常带 ACK。服务器进入LAST_ACK状态等待最终确认。报文格式FIN1, ACK1, Seqw, Acku1第四步ACK主动关闭方 → 被动关闭方客户端收到 FIN 后回复ACK1。确认号Ack w 1。客户端进入TIME_WAIT状态等待2MSL最长报文段寿命后关闭。服务器收到 ACK 后立即进入CLOSED状态。报文格式ACK1, Sequ1, Ackw1为什么需要四次挥手因为 TCP 是全双工的关闭需要两个方向独立进行客户端关闭发送通道第一次挥手。服务器确认收到关闭请求第二次挥手。服务器关闭发送通道第三次挥手。客户端确认收到关闭请求第四次挥手。特殊情况第二步和第三步有时可以合并如果服务器没有剩余数据发送。关键状态与计时器1. TIME_WAIT 状态2MSL 等待持续时间通常 2×MSLMSL 常设为 60s故 TIME_WAIT 为 120s。作用确保最后一个 ACK 能到达服务器若丢失服务器会重发 FIN。让本连接的所有报文在网络中消失避免新旧连接数据混淆。2. CLOSE_WAIT 状态表示被动关闭方等待上层应用调用 close()发送 FIN。大量 CLOSE_WAIT 可能意味着应用未正确关闭连接如未调用 close。挥手过程图示客户端主动关闭 服务器被动关闭 | | |---- FIN (Sequ) -------| 【FIN_WAIT_1】 |--- ACK (Acku1) ------| 【CLOSE_WAIT】 | | 服务器可能继续发送数据 |--- FIN (Seqw, Acku1)| 【LAST_ACK】 |---- ACK (Ackw1) -----| 【TIME_WAIT】 |等待 2MSL |立即关闭 |CLOSED |CLOSED异常情况处理FIN_WAIT_2 无限等待若服务器不发送 FIN例如应用崩溃客户端会一直等待。可通过设置tcp_fin_timeout超时。TIME_WAIT 过多高并发短连接服务器可能遇到可通过调整内核参数重用端口net.ipv4.tcp_tw_reuse1# 允许 TIME_WAIT 连接重用net.ipv4.tcp_tw_recycle0# 不建议开启NAT 问题同时关闭双方同时发送 FIN会进入CLOSING状态然后交换 ACK 后直接进入 TIME_WAIT。与三次握手的本质区别握手同步初始序列号可合并 ACK 与 SYN二次确认。挥手双向独立关闭因被动关闭方可能需要继续发送数据ACK 与 FIN 通常分离。