当前位置:   article > 正文

TCP / IP的连接以及状态码和标志位_tcp ip:ssh (established)

tcp ip:ssh (established)

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连接与断开全过程图解**
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头
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/158634
推荐阅读
相关标签
  

闽ICP备14008679号