|
与 TCP/UDP 类似需要在传输数据前设置一些请求头，不同的是 HTTP 是一个 “纯文本” 的协议，所有的头都是 ASCII 码的文本，很容易看出来是什么。
再者就是他的请求报文与响应报文的结构基本一样，主要三大部分组成：
-
起始行(Start Line)：描述请求或者响应的基本信息。
-
Header：使用 key-value 的形式详细说明报文信息。
-
空行。
-
消息正文(Entity)：传输的数据，图片、视频、文本等都可以。
这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。
敲黑板了
HTTP 协议规定报文必须包含 Header，而且之后必须有一个 “空行”，也就是“CRLF”，十六进制的“0D0A”，可以没有 “body”。
报文结构如下图所示：
客户端：
-
SYN_SENT - 客户端发起第 1 次握手后，连接状态为 SYN_SENT ，等待服务端内核进行应答，如果服务端来不及处理(例如服务端的 backlog 队列已满)就可以看到这种状态的连接。
-
ESTABLISHED - 表示连接处于正常状态，可以进行数据传送。客户端收到服务器回复的 SYN+ACK 后，对服务端的 SYN 单独回复(第 3 次握手)，连接建立完成，进入 ESTABLISHED 状态。服务端程序收到第 3 次握手包后，也进入 ESTABLISHED 状态。
-
FIN_WAIT_1 - 客户端发送了关闭连接的 FIN 报文后，等待服务端回复 ACK 确认。
-
FIN_WAIT_2 - 表示我方已关闭连接，正在等待服务端关闭。客户端发了关闭连接的 FIN 报文后，服务器发回 ACK 应答，但是没进行关闭，就会处于这种状态。
-
TIME_WAIT - 双方都正常关闭连接后，客户端会维持 TIME_WAIT 一段时间，以确保最后一个 ACK 能成功发送到服务器端。停留时长为 2 倍的 MSL (报文最大生存时间)，Linux 下大约是 60 秒。所以在一个频繁建立短连接的服务器上通常可以看到成千上万的 TIME_WAIT 连接。
服务端：
-
LISTEN - 表示当前程序正在监听某个端口时。
-
SYN_RCVD - 服务端收到第 1 次握手后，进入 SYN_RCVD 状态，并回复一个 SYN+ACK(第 2 次握手)，再等待对方确认。
-
ESTABLISHED - 表示连接处于正常状态，可以进行数据传送。完成 TCP3 次握手后，连接建立完成，进入 ESTABLISHED 状态。
-
CLOSE_WAIT - 表示客户端已经关闭连接，但是本地还没关闭，正在等待本地关闭。有时客户端程序已经退出了，但服务端程序由于异常或 BUG 没有调用 close()函数对连接进行关闭，那在服务器这个连接就会一直处于 CLOSE_WAIT 状态，而在客户机已经不存在这个连接了。
-
LAST_ACK - 表示正在等待客户端对服务端的关闭请求进行最终确认。
TIME_WAIT 状态存在的理由：
划重点了
-
可靠地实现 TCP 全双工连接的终止 在进行关闭连接四路握手协议时，最后的 ACK 是由主动关闭端发出的，如果这个最终的 ACK 丢失，服务器将重发最终的 FIN，因此客户端必须维护状态信息允 许它重发最终的 ACK。如 果不维持这个状态信息，那么客户端将响应 RST 分节，服务器将此分节解释成一个错误( 在 java 中会抛出 connection reset 的 SocketException)。因而，要实现 TCP 全双工连接的正常终 止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭 的客户端必须维持状 态信息进入 TIME_WAIT 状态。
-
允许老的重复分节在网络中消逝 TCP 分节可能由于路由器异常而“迷途”，在迷途期间，TCP 发送端可能因确认超时而重发这个 分节，迷途的分节在路由器修复后也会被送到最终目的地，这个 原来的迷途分节就称为 lost duplicate。在关闭一个 TCP 连接后，马上又重新建立起一个相同的 IP 地址和端口之间的 TCP 连接，后一个连接被称为前一个连接的化身 ( incarnation)，那么有可能出现这种情况，前一 个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。为了避免 这个情 况，TCP 不允许处于 TIME_WAIT 状态的连接启动一个新的化身，因为 TIME_WAIT 状 态持续 2MSL，就可以保证当成功建立一个 TCP 连接的时 候，来自连接先前化身的重复分组已 经在网络中消逝。
另外回答断链的问题时，可以提到实际应用中有可能遇到大量 Socket 处在 TIME_WAIT 或者 CLOSE_WAIT 状态的问题。一般开启 tcp_tw_reuse 和 tcp_tw_recycle 能够加快 TIME-WAIT 的 Sockets 回收;而大量 CLOSE_WAIT 可能是被动关闭的一方存在代码 bug，没有正确关闭链接导致的。
简单地说就是
-
保证 TCP 协议的全双工连接能够可靠关闭;
-
保证这次连接的重复数据段从网络中消失，防止端口被重用时可能产生数据混淆;
服务器处理请求并响应 HTTP 报文
深入分析下 HTTP 报文到底是什么玩意。数据传输都是通过 TCP/IP 协议负责底层的传输工作， HTTP 协议基本不用操心，所谓的 “超文本传输协议” 似乎不怎么例会 “传输” 这个事情，那 HTTP 的核心又是什么呢?
比图 TCP 报文，它在实际要传输的数据之前附加了一个 20 字节的头部数据，存储 TCP 协议必须的额外信息，例如发送方的端口号、接收方的端口号、包序号、标志位等等。
有了这个附加的 TCP 头，数据包才能够正确传输，到了目的地后把头部去掉，就可以拿到真正的数据。这个很容易理解，设置起点与终点，不同协议贴上不同的头部，到了对应目的地就拆下这个头部，提取真正的数据。
（编辑：威海站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
