zoukankan      html  css  js  c++  java
  • 一、TCP协议、报文、三次握手、四次挥手、七层网络模型、网关、路由器、路由交换机

    1.TCP协议、报文、三次握手、必要性、第三次握手丢失处理、四次挥手
    1.1 TCP协议
        传输控制协议(英语:Transmission Control Protocol,缩写为 TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议。在传输数据之前,TCP 在源节点和目标节点之间创建连接并使其保持有效直到通信处于活动状态。TCP 将大数据分成较小的数据包,并确保在目标节点重组后数据完整性保持不变。TCP 与 Internet 协议协同工作,Internet 协议定义远程节点的逻辑位置,而 TCP 传输并确保将数据传递到正确的目标。
        TCP 层(传输层)是位于 IP(网络层) 层之上,应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接,但是 IP 层不提供这样的流机制,而是提供不可靠的包交换。应用层向 TCP 层发送用于网间传输的、用 8 位字节表示的数据流,然后 TCP 把数据流分割成适当长度的报文段(通常受该计算机连接的网络的数据链路层的最大传输单元(MTU)的限制)。之后 TCP 把结果包传给 IP 层,由它来通过网络将包传送给接收端实体的 TCP 层。TCP 为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据包就被假设为已丢失将会被进行重传。TCP 用一个校验和函数来检验数据是否有错误;在发送和接收时都要计算校验和。
    1.2 TCP报文格式

    导图:

      1) 序列号seq:占32位(4字节),用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
      2) 确认号ack:占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号
      3) 确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
      4) 同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0
      5) 标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
      URG:紧急指针是否有效,1-表示某一位需要被优先处理    (urgent紧急)
      ACK:确认号是否有效,一般置为1                        (acknowledgement 确认)
      PSH:提示接收端应用程序立即从TCP缓冲区把数据读走     (push传送)
      RST:对方要求重新建立连接,复位                        (reset重置)
      SYN:请求建立连接,并在其序列号的字段进行序列号的初始值设定。建立连接,设置为1  (synchronous建立联机)
      FIN:希望断开连接,FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接 (finish结束)
    备注:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。

     1.3 TCP三次握手、必要性、第三次握手丢失如何处理

    导图:

    1、三次握手的理解:
      第一次握手:主机A发送位码为SYN=1,随机产生seq number=x的数据包到服务器,客户端进入SYN_SEND状态,等待服务器的确认;主机B由SYN=1知道A要求建立连接;
      第二次握手:主机B收到请求后要确认连接信息,向A发送ack number(主机A的seq+1)、SYN=1、ACK=1,随机产生seq=y的包,此时服务器进入SYN_RECV状态;
      备注:acknowledge  承认、告已收到
      第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ACK是否为1,若正确,主机A会再发送ack number(主机B的seq+1)、ACK=1,主机B收到后确认seq值与ACK=1则连接建立成功。客户端和服务器端都进入ESTABLISHED状态
      备注:ack的值为上一次握手的随机数据包值+1;

    2、三次握手的必要性:
      第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
      第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
      第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收能力,服务器自己的发送能力也正常。
    至此,客户端和服务端可以确定双方的接收和发送能力均正常。

    3、第三次握手的必要性:
    这主要是为了防止已失效的连接请求报文段突然又传送到了服务器端,从而减少服务端的开销。如果只有两次握手就建立连接会出现这种情况:客户端发出的连接请求报文段在某些网络节点长时间滞留了,以致延误到连接释放以后的某个时间才能到达服务端。本来这是一个早已失效的报文段,但服务端收到此失效的连接请求报文段后,就误认为客户端又发出了一次新的连接请求。于是向客户端发出确认报文段,同意建立连接。由于现在客户端并没有发出建立连接的请求,因此不会处理服务端的确认,也不会向服务端发送数据。但服务端却以为新的连接已经建立了,并一直等待客户端发来数据。 服务端会因此浪费很多了。

    4、如果第三次握手丢失了,客户端服务端会如何处理?
    a.服务端:
      该TCP连接的状态为SYN_RECV,并且会根据TCP的超时重传机制,会等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。而Server重发SYN+ACK包的次数,可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改,默认值为5。如果重发指定次数之后,仍然未收到客户端的ACK应答,那么一段时间后,服务端自动关闭这个连接。
    b.客户端:
      客户端在接收到SYN+ACK包,它的TCP连接状态就为ESTABLISHED(已连接),表示该连接已经建立。那么如果第三次握手中的ACK包丢失的情况下,客户端向服务端发送数据,服务端将以RST包(reset重置)响应,才能感知到服务端的错误。

    1.4 TCP四次挥手
    1、四次挥手的理解
      第一次挥手:主机A(可以是客户端,也可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机B发送一个FIN报文段;此时,主机A进入FIN_WAIT_1状态;这表示主机A没有数据要发送给主机B了。
      第二次挥手:主机B收到了主机A发送的FIN报文段,向主机A回一个ACK报文段,Acknowledgment Number为Sequence Number加1,主机1进入FIN_WAIT_2状态;主机2告诉主机A,我也没有数据要发送了,可以进行关闭连接了。
      第三次挥手:主机B向主机A发送FIN报文段,请求关闭连接,同时主机B进入CLOSE_WAIT状态。
      第四次挥手:主机A收到主机B发送的FIN报文段,向主机B发送ACK报文段,然后主机A进入TIME_WAIT状态;主机B收到主机A的ACK报文段以后,就关闭连接;此时,主机A等待2MSL后依然没有收到回复,则证明主机B已正常关闭,那好,主机A也可以关闭连接了。主机B发送了FIN-ACK之后,会立即启动超时重传计时器主机A在发送最后一个ACK之后,会立即启动时间等待计时器。

    2、挥手为什么需要四次    

      因为当服务端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当服务端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉客户端,"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四次挥手。

    3、四次挥手释放连接时,等待2MSL的意义
      为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。
      MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。我们都知道IP头部中有个TTL字段,TTL是time to live的缩写,可译为“生存时间”,这个生存时间是由源主机设置初始值代表一个IP数据包可以经过的最大路由数,每经过一个路由器,它的值就减1,当此值为0则数据报被丢弃,同时发送ICMP报文通知源主机。RFC793中规定MSL为2分钟,但这完全是从工程上来考虑,对于现在的网络,常用值30秒或1分钟。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。

    1.5七层网络模型:导图

    1.6 浏览器请求完整过程
    1、向浏览器输入请求到请求完成的整个过程
         a.查询本地计算机有没有存储域名baidu.com 对应的服务器IP。如果存储了,浏览器直接向目标服务器发起三次握手的连接请求;

      b.如果没有存储,则向DNS服务器发起"查询baidu.com对应服务器IP"的请求,DNS服务器返回baidu.com对应的目标IP后,向目标IP发起三次握手的连接请求,如果连接成功,则在本地备份目标IP

        c.连接成功后,服务端将相应数据返回给客户端进行显示。

    2、为什么MAC地址与IP地址缺一不可:
        将请求发送到目标IP的具体细节(为什么MAC地址与IP地址缺一不可) : 在OSI七层协议中MAC地址属于第二层数据链路层, IP地址属于第三层网络层, 浏览器发出的请求时, 会发起ARP广播,查询本地网络中,是否存在目标IP主机, 如果存在, 直接将浏览器请求的MAC地址定为目标IP主机的MAC地址, 如果不存在, 则将浏览器请求的MAC地址定为本地网络环境中路由器A的MAC地址,路由器A会将浏览器请求转发到另一个网络的路由器B(请求的mac地址被修改, 修改为路由器B的mac地址), 路由器B子网内如果存在目标主机IP, 则直接将浏览器请求的ip地址修改为目标主机的MAC地址,如果不存在, 则转发给浏览器C, 通过不断地修改请求MAC地址完成了浏览器请求在互联网内的层层接力,最终到达目标IP主机

    1.7.网关、路由器、路由、交换机器
    1)“网关”:让两个不同网络相互之间进行通信,可以使具有不同协议的网络相互连接。
    网关是一个协议转化器,可以接受一种协议的数据包如AppleTalk格式的包,然后再转发之前将其转化成另一种协议形式的包如 TCP/IP格式继而发送出去。可以说网关可以更改数据包的格式,而路由器则不能。
    2)“路由器”:能在计算机网络之间发送和接收数据包的设备,并且提供最佳路由路径的一种网络互联设备。但是只能在使用相同协议的网络中转发数据包。

    1.8 响应状态码类型及含义
    1)状态码分类:
    1XX:信息型,服务器收到请求,需要请求者继续操作;
    2XX:成功型,请求成功收到,理解并处理;
    3XX:重定向,需要进一步的操作以完成请求;
    4XX:客户端错误,请求包含语法错误或无法完成请求;
    5XX:服务器错误,服务器在处理请求的过程中发生了错误;
    2)常见状态码:
    200:客户端请求成功;
    301:资源(网页等)被永久转移到其它URL;
    302:临时跳转;
    400:是一种错误请求,客户端请求有语法错误,不能被服务器所理解;
    401:未经授权的一种请求,这个状态代码必须和WWW-Authenticate报头域一起使用;
    404:请求资源不存在,可能是输入了错误的URL;
    500:服务器内部发生了不可预期的错误;
    503:服务器当前不能处理客户端的请求,一段时间后可能恢复正常;

    参看博文:

    https://www.jianshu.com/p/11add30ee652

  • 相关阅读:
    希尔伯特空间
    Java基础之类型转换总结篇
    超实用在线编译网站,编辑器
    3269: 万水千山粽是情
    Problem A: 李白打酒
    2370: 圆周率
    C语言fmod()函数:对浮点数取模(求余)
    C语言exp()函数:e的次幂函数(以e为底的x次方值)
    2543: 数字整除
    2542: 弟弟的作业
  • 原文地址:https://www.cnblogs.com/jiarui-zjb/p/12821947.html
Copyright © 2011-2022 走看看