zoukankan      html  css  js  c++  java
  • TCP/IP协议

    一、常见设备工作层次 (来自http://www.yacer.cn/jishu/doc-147.html)

     看一个设备工作在哪一层,需要看它的主要实现功能使用的是哪一层协议头信息。

    • 网卡物理层上网卡主要是完成物理接口的连接,电信号的传送以及将数据分解为适当大小的数据包之后向网络上发送的功能。数据链路层功能包括链路建立和拆除,帧定界同步顺序差错控制这些。大多认为主要工作在物理层。 
    • 网桥数据链路层,在不同或相同类型的LAN之间存储并转发数据帧,必要时进行链路层上的协议转换。可连接两个或多个网络,在其中传送信息包。
    • 交换机数据链路层,原理等同于多端口网桥。作用是连接数个相同网段的不同主机,减少网内冲突,隔离冲突域。利用存储转发和过滤技术来从物理上分割网段。
    • 路由器网络层,在不同的网络间存储并转发分组。可在异种网络之间(即不同类型的局域网互连,局域网与广域网,广域网与广域网)传输数据并进行路径选择,使用专门的软件协议从逻辑上对整个网络进行划分。
    • 网关对高层协议(包括传输层及更高层次)进行转换的网间连接器。协议转换是网关最重要的功能,所以答案是工作在传输层及以上层次

    二、OSI七层模型

     

    三、三次握手和四次挥手

    • 三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

    1.第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;

    2.第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;

    3.第三次握手客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

    • 为什么要三次握手?

    为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。防止服务器端的一直等待而浪费资源。

    "已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。"

    •  四次分手

    1.第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

    2.第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我也没有数据要发送了,可以进行关闭连接了;

    3.第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入CLOSE_WAIT状态;

    4.第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。

    • 为什么要四次分手?

    需要双方都确认自己没有数据需要再传输

    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连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。 (主动方)

    CLOSE_WAIT:表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN 报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实 际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close这个 SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)

    LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报 文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。(被动方)

    TIME_WAIT: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。 如果FINWAIT1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方) 

    CLOSED: 表示连接中断。

    RTT:一个TCP分段的回复到达的时间就是一个数据报往返的时间,代表一个TCP分段的往返时间。 

    四、TCP慢启动、拥塞避免、快速重传、快速恢复

    TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制。窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段。

    慢启动:最初的TCP在连接建立成功后会向网络中发送大量的数据包,这样很容易导致网络中路由器缓存空间耗尽,从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包,而只能根据网络情况逐步增加每次发送的数据量,以避免上述现象的发生。

    具体来说,当新建连接时,cwnd初始化为1个最大报文段(MSS)大小,发送端开始按照拥塞窗口大小发送数据,每当有一个报文段被确认,cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round Trip Time,RTT)呈指数级增长,事实上,慢启动的速度一点也不慢,只是它的起点比较低一点而已。

    拥塞避免:从慢启动可以看到,cwnd可以很快的增长上来,从而最大程度利用网络带宽资源,但是cwnd不能一直这样无限增长下去,一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量,当cwnd超过该值后,慢启动过程结束,进入拥塞避免阶段。对于大多数TCP实现来说,ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大,也就是cwnd的值不再指数级往上升,开始加法增加。此时当窗口中所有的报文段都被确认时,cwnd的大小加1,cwnd的值就随着RTT开始线性增加,这样就可以避免增长过快导致网络拥塞,慢慢的增加调整到网络的最佳值。

    超时重传:看TCP是如何确定网络进入了拥塞状态的,TCP认为网络拥塞的主要依据是它重传了一个报文段。TCP对每一个报文段都有一个定时器,称为重传定时器(RTO),当RTO超时且还没有得到数据确认,那么TCP就会对该报文段进行重传。

  • 相关阅读:
    shell预备知识
    php session和cookie
    php数据库访问抽象层PDO
    递归求斐波那契数
    SqlDataReader的使用
    DataAdapter与DataSet的使用
    CLR
    Android Studio javadoc 生成注释文档
    MySQL教程之concat以及group_concat的用法
    一文读懂MQTT协议
  • 原文地址:https://www.cnblogs.com/coolqiyu/p/5695465.html
Copyright © 2011-2022 走看看