当前位置:   article > 正文

【网络协议】TCP/IP 协议_pcpit的相关协议

pcpit的相关协议
1、TCP/IP 模型
  • TCP/IP 协议模型,包含了一系列构成互联网基础的网络协议,是 Internet 的核心协议。
  • 基于 TCP/IP 协议栈可分为四层或五层,转换为 OSI 参考模型,可以分为七层,分别如下图所示:
    TCP/IP、OSI 模型图
  • 通常我们所说的都是基于 TCP/TP 五层模型。
2、TCP/IP 协议栈每一层功能
  • 应用层:HTTP、FTP 等等我们熟悉的协议。
  • 传输层:TCP 和 UDP 协议、HTTPS。
  • 网络层:IP 协议,它负责对数据加上 IP 地址和其他的数据以确定传输的目标。
  • 数据链路层:为待传送的数据加入一个以太网协议头,并进行 CRC 编码,为最后的数据传输做准备。
  • 物理层:二进制数据流传输。
3、IP 协议
  • IP 协议 是TCP/IP 协议的核心,所有的 TCP、UDP、ICMP、IGCP 的数据都以 IP 数据格式传输。要注意的是,IP 不是可靠的协议,这是说,IP 协议没有提供一种数据未传达以后的处理机制,这被认为是上层协议 TCP 或 UDP 要做的事情。
  • IP 协议属于面向无连接协议。
4、IP 分片与重组
  • 对于不同的数据链路,其最大传输单元(MTU,单位字节)不同。当 IP 数据包中的字节数无法在一个帧中发送,路由器就会将此 IP 数据报划分成数个片。而这种分片处理只要路由器认为有必要,就会周而复始的进行。
  • 经过分片之后的 IP 数据报只能由目标主机进行重组,路由器不会处理。(如果路由器要处理重组的话,到下个路由器也可能被分片,这样就会降低传送效率。)
  • 路径 MTU 发现技术:路径 MTU 是指从发送端主机到接收端主机之间不需要分片时最大的 MTU 大小。即路径中存在的所有数据链路中最小的 MTU。该技术可以避免在中途的路由器上进行分片处理,也可以针对传输层发送更大的包。提高传送效率与网络利用率,降低分片丢失分险。
5、相关协议
  • DNS:将网址转换为 IP。即域名解析,通过域名服务器查询网址对应的 IP。
  • ARP:将 IP 定位到对应的 MAC 地址。(通过广播发送一个ARP请求包(包含目标I P 地址),发送到链路上的所有主机或者路由器,如果某个节点的 IP 与其一致,则将自己的 MAC 地址塞入 ARP 响应包中返回给发送者。)
  • RARP:将 MAC 对应上 IP 地址。(需要对应的 RARP 服务器,当物理设备接入后,告诉服务器自己的 MAC 地址,然后服务器分配对应的 IP 地址。)
  • ICMP:确认 IP 包是否成功到达目标地址,通知在发送过程中 IP 包被废弃的具体原因,改善网络设置等。当某个路由器持有 IP 包,且发现问题后,如未能发现目标主机存在,则会像发送方反馈一个 ICMP 包,说明问题原因。
  • DCHP:为设备自动设置 IP 地址,统一管理 IP 地址分配。实现即插即用。基于 DCHP 服务器,将要分配的 IP 地址、相应的子网掩码、路由控制信息、DNS 服务器的地址等设置到服务器上,设备接入后,就自动为其分配事先配置的 IP 地址。
  • NAT:将本地网络中的私有地址,在连接互联网时转而使用全局 IP 地址的技术。通过 NAT 路由映射私有 IP 地址与全局 IP 地址。
5、TCP/UDP
  • TCP/UDP 都是是传输层协议,但是两者具有不同的特性,同时也具有不同的应用场景,下面以图表的形式对比分析。
作用TCPUDP
可靠性可靠不可靠
连接性面向连接无连接
报文面向字节流面向报文
效率传输效率低传输效率高
双工性全双工一对一、一对多、多对一、多对多
流量控制滑动窗口
拥塞控制慢开始、拥塞避免、快重传、快恢复
传输速度
应用场景对效率要求低,对标准性要求高或者要求有连接的场景对效率要求高,对准确性要求低
  • 面向字节流:面向字节流的话,虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序看成是一连串的无结构的字节流。TCP 有一个缓冲,当应用程序传送的数据块太长,TCP 就可以把它划分短一些再传送。
  • 面向报文:面向报文的传输方式是应用层交给 UDP 多长的报文,UDP 发送多长的报文,即一次发送一个报文。因此应用程序必须选择合适大小的报文,若报文太长,则 IP 层需要分片,降低效率,若太短,会使 IP 数据报太小。
6、什么时候使用 TCP?什么时候使用 UDP?
  • 当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如: HTTP、HTTPS、FTP 等传输文件的协议,POP、SMTP 等邮件传输的协议。
  • 当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用 UDP,比如:微信语音、微信视频、直播等。
7、TCP 连接的建立与终止
(1)TCP 三次捂手建立连接
  • 三次握手的主要作用:确认双方的接收能力和发送能力是否正常、指定自己的初始序列号(ISN)为后面的可靠性传输做准备。

  • TCP是面向连接的,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。在TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。
    TCP 三次握手过程图

  • 第一次握手:客户端向服务端发送一个 SYN 报文(SYN = 1),并指明客户端的初始序列号 ISN(x),即图中的 seq = x,表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN 发送(SYN_Send)状态。

  • 第二次握手:服务器收到客户端的 SYN 报文之后,会发送 SYN 和 ACK 报文作为应答(SYN = 1 , ACK = 1),并且指定自己的初始序列号 ISN(y),即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值,表示已经收到了客户端发来的的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 x + 1,此时服务器处于 SYN 收到(SYN_RECV => SYN_RECEIVED)的状态。

  • 第三次握手:客户端收到服务器端响应的 SYN 报文之后,会发送一个 ACK 报文,也是一样把服务器的 ISN + 1 作为 ack 的值,表示已经收到了服务端发来的的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 y + 1,并指明此时客户端的序列号 seq = x + 1(初始为 seq = x,所以第二个报文段要 +1),此时客户端处于建立连接(ESTABLISHED)状态,同时服务器收到 ACK 报文之后,也处于建立连接(ESTABLISHED)状态,至此双方建立起了 TCP 连接。

(2)TCP 四次挥手释放连接
  • 当客户端和服务端通过三次握手建立了 TCP 连接以后,且数据传送完毕,肯定是要断开 TCP 连接的。那对于TCP的断开连接,这里就有了神秘的“四次挥手”。

  • 注意:客户端和服务端均可主动发起挥手动作。
    TCP 四次挥手过程图

  • 第一次挥手:客户端发送一个 FIN 报文(请求连接终止:FIN = 1),报文中会指定一个序列号 seq = u。并停止再发送数据,主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态,等待服务端的确认。

  • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 u + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。此时的 TCP 处于半关闭状态,客户端到服务端的连接释放。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待 2)状态,等待服务端发出的连接释放报文段。

  • 第三次挥手:如果服务端也想断开连接了(没有要向客户端发出的数据),和客户端的第一次挥手一样,发送 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态,等待客户端的确认。

  • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答(ack = w+1),且把服务端的序列值 +1 作为自己 ACK 报文的序号值(seq=u+1),此时客户端处于 TIME_WAIT (时间等待)状态,等待 2MSL(一个报文的来回时间)后依然没有收到回复,则证明服务端已经正常关闭,那么客户端也可以关闭连接了。

8、为什么要三次握手?为什么不能进行两次握手连接?
  • 三次握手最主要的目的是需要确认客户端和服务端都有发送和接受的能力。
  • 如果只采用两次捂手,服务端不能判断客户端是否能接受数据的能力,并且如果采用两次握手的话,已失效的连接请求报文段突然又传送到了服务端,服务端返回确认报文段给客户端,以为双方再次确立连接,等待客户端的数据。但客户端实际上并没有发送连接请求报文段,不会传送数据给服务端,服务端就会等着,浪费资源。(虽说 TCP 还有保活计时器)
9、ISN(初始序列号)是固定的吗?
  • 不是固定的,三次握手的其中一个重要功能是客户端和服务端交换 ISN(初始序列号),以便让对方知道接下来接收数据的时候如何按序列号组装数据。
  • 当一端为建立连接而发送它的 SYN 时,它会为连接选择一个初始序号。ISN 随时间而变化,因此每个连接都将具有不同的 ISN。如果 ISN 是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。
10、三次握手过程中可以携带数据吗?
  • 第三次握手的时候是可以携带数据,但是第一次和第二次绝对不可以携带数据。
  • 假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN 报文中放入大量的数据,然后疯狂重复发 SYN 报文的话(因为攻击者根本就不用管服务器的接收、发送能力是否正常,它就是要攻击你),这会让服务器花费很多时间、内存空间来接收这些报文。而对于第三次的话,此时客户端已经处于建立连接状态(ESTABLISHED),并且也已经知道服务器的接收、发送能力是正常的了,所以当然能正常发送/携带数据了。
11、什么叫半连接队列?
  • 服务器第一次收到客户端的 SYN 之后,就会处于 SYN 收到状态(SYN_RCVD),此时双方还没有完全建立其连接,服务器会把这种状态下的请求连接放在一个队列里,我们把这种队列称之为半连接队列。
  • 当然还有一个全连接队列,完成三次握手后建立起的连接就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
12、什么是 SYN 洪泛攻击?
  • SYN 攻击就是客户端在短时间内伪造大量不存在的 IP 地址,并向服务端不断地发送 SYN 包,服务端则回复确认包,并等待客户端确认,由于源地址不存在,因此服务端需要不断重发直至超时,这些伪造的 SYN 包将长时间占用半连接队列,导致正常的 SYN 请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。
13、如果第三次握手丢失了,客户端服务端会如何处理?
  • 服务器发送完 SYN-ACK 包,如果未收到客户端响应的确认包,也即第三次握手丢失。那么服务器就会进行首次重传,若等待一段时间仍未收到客户确认包,就进行第二次重传。如果重传次数超过系统规定的最大重传次数,则系统将该连接信息从半连接队列中删除。
  • 注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s,2s,4s,8s…
14、如果已经建立了连接,但是客户端突然出现故障了怎么办?
  • TCP 设置有一个保活计时器,服务器每一次收到数据就会重新复位这个计时器,若计时器走完,没有收到客户端的数据,服务器就会发送探测报文,75秒一个探测报文,连续10个探测报文没有收到回复,就认为客户端故障,断开连接。
15、为什么要四次挥手?
  • TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议,且 TCP 是全双工模式,这就意味着当客户端发出 FIN 报文段时,只是表示客户端数据已全部发送完毕了,但是这个时候客户端还是可以接受来自服务端的数据;当服务端返回 ACK 报文段时,表示它已经知道客户端没有数据发送了,但是服务端还是可以发送数据到客户端的;当服务端也发送了 FIN 报文段时,这个时候就表示服务端也没有数据要发送了,就会告诉客户端我也没有数据要发送了,之后彼此就会愉快的中断这次 TCP 连接。
16、为什么第四次挥手要等待 2MSL?
  • MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。
  • 原因有二:(1)保证 TCP 协议的全双工连接能够可靠关闭;(2)保证本次连接的所有数据从网络中消失。
  • 第一点:如果客户端直接关闭了,那么由于 IP 协议的不可靠性或者是其它网络原因,导致服务端没有收到客户端最后回复的 ACK 报文。那么服务端就会在超时之后继续发送 FIN,此时由于客户端已经关闭了,就找不到与重发的 FIN 对应的连接。所以客户端不是直接进入关闭状态,而是要保持 TIME_WAIT 状态。当再次收到 FIN 的时候,能够保证对方收到 ACK,最后正确的关闭连接。
  • 第二点:如果客户端直接关闭,然后又再向服务端发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中(称为 Lost Duplicate),这些延迟数据在建立新连接之后才到达服务端,由于新连接和老连接的端口号是一样的,TCP 协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以 TCP 连接要在 TIME_WAIT 状态等待 2MSL,保证本次连接的所有数据都从网络中消失。
17、打开一个网页会经历什么?
  • 首先在浏览器地址栏输入一个 URL,然后浏览器根据你输入的 URL 去查看浏览器缓存器缓存信息,如果缓存中有则直接从缓存中取出相对于的 IP 地址,如果没有则进行 DNS 域名解析,然后获取到相对于的 IP 地址。
  • 解析出 IP 地址后,再根据 IP 地址和默认端口跟服务端开始尝试建立 TCP 连接。
  • 通过 TCP 三次握手之后,成功与服务端建立连接,并发出响应的数据请求。
  • 服务端收到请求,并对浏览器做出相应的响应,并发送给浏览器。
  • 通过 TCP 四次挥手释放连接。
  • 浏览器收到 Response 数据,然后将数据解析并渲染到页面上。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小惠珠哦/article/detail/784216
推荐阅读
相关标签
  

闽ICP备14008679号