（1）http 状态码： 1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码2xx （成功）
表示成功处理了请求的状态码。
常见的 2 开头的状态码有：200 – 服务器成功返回网页3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定
向
常见的 3 字开头的状态码有：
301（永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应时，会自动将请求者转到新位置。
302（临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
304 （未修改） 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
4xx（请求错误） 这些状态代码表示请求可能出错，妨碍了服务器的处理。
常见的 4 字开头的状态有：404 – 请求的网页不存在5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
常见的以 5 开头的状态码有：
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态
（2）三次握手和四次挥手：三次握手:
TCP 协议中，主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，TCP 连接建立完后都能发送和接收数据。
起初，服务器和客户端都为 CLOSED 状态。在通信开始前，双方都得创建各自的传输控制块（TCB）。
服务器创建完 TCB 后遍进入 LISTEN 状态，此时准备接收客户端发来的连接请求。
第一次握手
客户端向服务端发送连接请求报文段。该报文段的头部中 SYN=1，ACK=0， seq=x。请求发送后，客户端便进入 SYN-SENT 状态。
•PS1：SYN=1，ACK=0 表示该报文段为连接请求报文。
•PS2：x 为本次 TCP 通信的字节流的初始序号。
TCP 规定：SYN=1 的报文段不能有数据部分，但要消耗掉一个序号。
第二次握手
服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1， ACK=1，seq=y，ack=x+1。
该应答发送完成后便进入 SYN-RCVD 状态。
•PS1：SYN=1，ACK=1 表示该报文段为连接同意的应答报文。
•PS2：seq=y 表示服务端作为发送者时，发送字节流的初始序号。
•PS3：ack=x+1 表示服务端希望下一个数据报发送序号从 x+1 开始的字节。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示： 服务端发来的连接同意应答已经成功收到。
该报文段的头部为：ACK=1，seq=x+1，ack=y+1。
客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接的建立完成！
为什么连接建立需要三次握手，而不是两次握手？
防止失效的连接请求报文段被服务端接收，从而产生错误。
***TCP 四次挥手：
TCP 连接的释放一共需要四步，因此称为『四次挥手』。
我们知道，TCP 连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。
第一次挥手
若 A 认为数据发送完成，则它需要向 B 发送连接释放请求。该请求只有报文头，头中携带的主要参数为：
FIN=1，seq=u。此时，A 将进入 FIN-WAIT-1 状态。
•PS1：FIN=1 表示该报文段是一个连接释放请求。
•PS2：seq=u，u-1 是 A 向 B 发送的最后一个字节的序号。·
第二次挥手
B 收到连接释放请求后，会通知相应的应用程序，告诉它 A 向 B 这个方向的连接已经释放。此时 B 进入 CLOSE-WAIT 状态，并向 A 发送连接释放的应答，其报文头包含：
ACK=1，seq=v，ack=u+1。
•PS1：ACK=1：除 TCP 连接请求报文段以外，TCP 通信过程中所有数据报的ACK 都为 1，表示应答。
•PS2：seq=v，v-1 是 B 向 A 发送的最后一个字节的序号。
•PS3：ack=u+1 表示希望收到从第 u+1 个字节开始的报文段，并且已经成功接收了前 u 个字节。
A 收到该应答，进入 FIN-WAIT-2 状态，等待 B 发送连接释放请求。
第二次挥手完成后，A 到 B 方向的连接已经释放，B 不会再接收数据，A 也不会再发送数据。但 B 到 A 方向的连接仍然存在，B 可以继续向 A 发送数据。
第三次挥手
当 B 向 A 发完所有数据后，向 A 发送连接释放请求，请求头：FIN=1，ACK=1， seq=w，ack=u+1。B 便进入 LAST-ACK 状态。
第四次挥手
A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态， 撤销 TCB。当 B 收到确认应答后，也便进入 CLOSED 状态，撤销 TCB。
为什么A 要先进入TIME-WAIT 状态，等待 2MSL 时间后才进入
CLOSED 状态？
为了保证 B 能收到 A 的确认应答。
若 A 发完确认应答后直接进入 CLOSED 状态，那么如果该应答丢失，B 等待超时后就会重新发送连接释放请求，但此时 A 已经关闭了，不会作出任何响应，因此 B 永远无法正常关闭。