赞
踩
这里我采用网上的三种解释方法
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:有两种方式进入该状态:
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 可用状态了。
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
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头
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。