TCP的状态码
这里我采用网上的三种解释方法
方式1
closed：无连接是活动 的或正在进行
listen：服务器在等待进入呼叫
syn_recv：一个连接请求已经到达，等待确认
syn_sent：应用已经开始，打开一个连接
established：正常数据传输状态
fin_wait1：应用说它已经完成
fin_wait2：另一边已同意释放
itmed_wait：等待所有分组死掉
closing：两边同时尝试关闭
time_wait：另一边已初始化一个释放
last_ack：等待所有分组死掉
方式二
close：起点，即初始状态；
listen:被动打开，服务器端的状态变为listen状态(监听）；
syn-recvd（同步收到）:服务器端收到syn后，状态为syn,发送syn+ack;
syn-sent（同步已发送）:应用程序发送syn后，状态为syn-sent;
established（已建立连接）:syn-recvd收到ack后，状态为established，syn-sent收到syn+ack,发送ack,状态为established；
close_wait（关闭等待）:服务器端在收到fin后，发送ack,状态变为close_wait,如果此时服务器端还有数据要传送，那么就发送，直到数据发送完毕，此时，服务器端发送fin，状态变为last-ack;
fin-wait-1：应用程序端发送fin,准备断开tcp连接，状态从established状态变为fin-wait-1;
fin-wait-2：应用程序端只有收到服务器端ack信号，并没有收到fin信号，说明服务器端还有数据要传输，那么此时为半连接；
time_wait:有两种方式进入该状态：
- 1.从fin-wait-1进入，此时应用程序端口收到fin+ack,并向服务器端口发送ack;
- 2.fin-wait-2进入，此时应用程序端口收到了fin,然后向服务器发送ack;
time-wait是为了实现tcp全双工连接的可靠性闭，用来重发可能丢失的ack报文，需要持续2msl，假如应用程序端口在进入time_wait后，2个msl时间内并没有收到fin,说明应用程序最后发出的ack已经收到了；
方式三
closed：初始状态，表示tcp连接是“关闭着的”或“未打开的”。
listen ：表示服务器端的某个socket处于监听状态，可以接受客户端的连接。
syn_rcvd ：表示服务器接收到了来自客户端请求连接的syn报文。在正常情况下，这个状态是服务器端的socket在建立tcp连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat很难看到这种状态，除非故意写一个监测程序，将三次tcp握手过程中最后一个ack报文不予发送。当tcp连接处于此状态时，再收到客户端的ack报文，它就会进入到established 状态。
syn_sent ：这个状态与syn_rcvd 状态相呼应，当客户端socket执行connect()进行连接时，它首先发送syn报文，然后随即进入到syn_sent 状态，并等待服务端的发送三次握手中的第2个报文。syn_sent 状态表示客户端已发送syn报文。
established ：表示tcp连接已经成功建立。
fin_wait_1 ：这个状态得好好解释一下，其实fin_wait_1 和fin_wait_2 两种状态的真正含义都是表示等待对方的fin报文。而这两种状态的区别是：fin_wait_1状态实际上是当socket在established状态时，它想主动关闭连接，向对方发送了fin报文，此时该socket进入到fin_wait_1 状态。而当对方回应ack报文后，则进入到fin_wait_2 状态。当然在实际的正常情况下，无论对方处于任何种情况下，都应该马上回应ack报文，所以fin_wait_1 状态一般是比较难见到的，而fin_wait_2 状态有时仍可以用netstat看到。
fin_wait_2 ：上面已经解释了这种状态的由来，实际上fin_wait_2状态下的socket表示半连接，即有一方调用close()主动要求关闭连接。注意：fin_wait_2 是没有超时的（不像time_wait 状态），这种状态下如果对方不关闭（不配合完成4次挥手过程），那这个 fin_wait_2 状态将一直保持到系统重启，越来越多的fin_wait_2 状态会导致内核crash。
time_wait ：表示收到了对方的fin报文，并发送出了ack报文。 time_wait状态下的tcp连接会等待2*msl（max segment lifetime，最大分段生存期，指一个tcp报文在internet上的最长生存时间。每个具体的tcp协议实现都必须选择一个确定的msl值，rfc 1122建议是2分钟，但bsd传统实现采用了30秒，linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值），然后即可回到closed 可用状态了。如果fin_wait_1状态下，收到了对方同时带fin标志和ack标志的报文时，可以直接进入到time_wait状态，而无须经过fin_wait_2状态。（这种情况应该就是四次挥手变成三次挥手的那种情况）
closing ：这种状态在实际情况中应该很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送fin报文后，按理来说是应该先收到（或同时收到）对方的ack报文，再收到对方的fin报文。但是closing 状态表示一方发送fin报文后，并没有收到对方的ack报文，反而却也收到了对方的fin报文。什么情况下会出现此种情况呢？那就是当双方几乎在同时close()一个socket的话，就出现了双方同时发送fin报文的情况，这是就会出现closing 状态，表示双方都正在关闭socket连接。
close_wait ：表示正在等待关闭。怎么理解呢？当对方close()一个socket后发送fin报文给自己，你的系统毫无疑问地将会回应一个ack报文给对方，此时tcp连接则进入到close_wait状态。接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()这个socket并发送fin报文给对方，即关闭自己到对方这个方向的连接。有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于close_wait 状态下，需要完成的事情是等待你去关闭连接。
last_ack ：当被动关闭的一方在发送fin报文后，等待对方的ack报文的时候，就处于last_ack 状态。当收到对方的ack报文后，也就可以进入到closed 可用状态了。
位码即TCP标志位,有6种标示:
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
SYN(synchronous建立联机)
Sequence Number(顺序号码)
Acknowledge Number(确认号码)
Tcp连接与断开全过程图解如下图：
TCP 状态迁移过程：
客户端：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务端
CLOSED -> LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE
[TCP/IP]常见的HTTP状态码
1XX 信息性状态码 接受的请求正在处理
2XX 成功状态码 请求处理完毕
3XX 重定向状态码 需要进行附加操作以完成请求
4XX 客户端错误状态码 服务器无法处理请求
5XX 服务器错误状态码 服务器处理请求出错
14种常见HTTP状态码
1 200 OK
一切正常，对GET和POST请求的应答文档跟在后面
2 204 No Content
没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新
3 206 Partial Content
客户端发送了一个带有Range头的GET请求，服务器完成了它
4 301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
5 302 Found
类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
6 303 See Other
类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
7 304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
8 307 Temporary Redirect
和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清楚地区分几个状态代码： 当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
9 401 Unauthorized
客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
10 403 Forbidden
资源不可用。
11 404 Not Found
无法找到指定位置的资源
12 406 Not Acceptable
指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容
13 500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求
14 503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头