[服务端与网络]http协议与http状态码-优快云博客

本文深入解析HTTP协议在TCP/IP网络中的工作原理，包括HTTP的无状态特性与TCP的三次握手和四次挥手过程。详细解释了HTTP/1.1后的keep-alive特性，TCP连接的建立与释放机制，及在此过程中的状态变化。同时，文章探讨了HTTP状态码的含义，如常见的200、301、404等。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

http协议

建立在tcp/ip网络协议(传输层)上的应用层协议

1.1后具有keep-alive,即从客户端第一次打开网页时所建立的tcp连接为一个有状态和时间的长连接。

而http之所叫无状态的短连接是因为每次浏览器发起请求都会建立一个新的tcp连接，根据这个连接通道来进行数据的请求传输，每次请求完成后即关闭该连接。当连接关闭后，服务器的内存中对应的进程（用来记忆一些信息）即被关闭，即状态的释放，即无状态。

TCP连接的三次握手（连接建立）四次挥手（连接释放）

三次握手

个人理解就是：

客户端（一群要去执行任务的人，需要连接信息部的人提供一些需要的信息数据）说： hi，能听到吗，收到请回复（电波发射，biubiubiu）
服务端耳麦里收到这段电波（进程被动打开），辨识了下电波的ip（熟人，可以回复），说：能（电波发射，biubiubiu）
客户端耳麦里传来能的电波，通知伙计们可以干活了（主动打开上层进程），然后对服务端说：ok，收到

在这个过程中，通信双方的状态如下图，其中CLOSED：关闭状态、LISTEN：收听状态、SYN-SENT：同步已发送、SYN-RCVD：同步收到、ESTAB-LISHED：连接已建立

至此，TCP连接就建立了，客户端和服务器可以愉快地玩耍了。只要通信双方没有一方发出连接释放的请求，连接就将一直保持。

四次挥手

个人理解：

客户端本次需要的信息数据全部接受完毕，开始收工，说：好了，这事基本完了我不再问你了，剩余的事你说我听就行了，并关闭了自己这边的麦克风（电波发射，biubiubiu）
服务端耳麦里收到这段电波，冷漠的回道：哦。收到。（电波发射，biubiubiu）然后服务端继续逼逼传信息数据（继续发送电波）
服务端检查了一会，伙计们说都ok了（进程提示服务端断开本次连接），于是服务端说：我说完了，拜
客户端耳麦听到后，说：好，收到（发出确认电波），经过2msl的时间后，本次连接通讯正式结束。

在这个过程中，通信双方的状态如下图，其中：ESTAB-LISHED：连接建立状态、FIN-WAIT-1：终止等待1状态、FIN-WAIT-2：终止等待2状态、CLOSE-WAIT：关闭等待状态、LAST-ACK：最后确认状态、TIME-WAIT：时间等待状态、CLOSED：关闭状态

解释几个问题：

1、在握手与挥手的过程中，往复的ack与seq有什么含义？

这是通信双方在通信过程中的一种确认手段，确保通信双方通信的正确性。例如小时候模仿电视剧里无线电呼叫的过程：“土豆土豆，我是地瓜，你能听到吗？”“地瓜地瓜，我是土豆，我能听到”。若客户端的报文请求号为“土豆”，则服务器端就将返回确认号“土豆+1”（标志土豆已收到），是一种通信双方的确认手段。

2、在结束连接的过程中，为什么在收到服务器端的连接释放报文段之后，客户端还要继续等待2MSL之后才真正关闭TCP连接呢？

这里有两个原因：第一个是：需要保证服务器端收到了客户端的最后一条确认报文。假如这条报文丢失，服务器没有接收到确认报文，就会对连接释放报文进行超时重传，而此时客户端连接已关闭，无法做出响应，就造成了服务器端不停重传连接释放报文，而无法正常进入关闭状态的状况。而等待2MSL，就可以保证服务器端收到了最终确认；若服务器端没有收到，那么在2MSL之内客户端一定会收到服务器端的重传报文，此时客户端就会重传确认报文，并重置计时器。

第二个是：存在一种“已失效的连接请求报文段”，需要避免这种报文端出现在本连接中，造成异常。

这种“已失效的连接请求报文段”是这么形成的：假如客户端发出了连接请求报文，然而服务器端没有收到，于是客户端进行超时重传，再一次发送了连接请求报文，并成功建立连接。然而，第一次发送的连接请求报文并没有丢失，只是在某个网络结点中发生了长时间滞留，随后，这个最初发送的报文段到达服务器端，会使得服务器端误以为客户端发出了新的请求，造成异常。

3、若通信双方同时请求连接或同时请求释放连接，情况如何？

这种情况虽然发生的可能性极小，但是是确实存在的，TCP也特意设计了相关机制，使得在这种情况下双方仅建立一条连接。双方同时请求连接的情况下，双方同时发出请求连接报文，并进入SYN-SENT状态；当收到对方的请求连接报文后，会再次发送请求连接报文，确认号为对方的SYN+1，并进入SYN-RCVD状态；当收到对方第二次发出的携带确认号的请求报文之后，会进入ESTAB-LISHED状态。双方同时请求释放连接也是同样的，双方同时发出连接释放报文，并进入FIN-WAIT-1状态；在收到对方的报文之后，发送确认报文，并进入CLOSING状态；在收到对方的确认报文后，进入TIME-WAIT状态，等待2MSL之后关闭连接。需要注意的是，这个时候虽然不用再次发送确认报文并确认对方收到，双方仍需等待2MSL之后再关闭连接，是为了防止“已失效的连接请求报文段”的影响。过程图如下：

http与tcp中大部分内容转载自博客园贰拾肆樵