网络原理TCP/IP

网络原理TCP/IP

​ 在TCP/IP协议中,我们可以使用"源IP",“源端口号”,“目的IP”,“目的端口号”,协议号"(应用层协议)这样的五元组进行标识一个通信.

两个问题:

  1. 一个进程是否能绑定多个端口号 可以

  2. 一个端口号是否能背多个进程绑定 不可以

常见面试题:

1.UDP的特点?

​ 见下

2.TCP和UDP的区别?
  1. 效率问题

    UDP效率高于TCP

  2. 安全问题.

TCP比UDP安全,但是TCP安全不是100%安全,相对安全

  1. 结合特点进行对比说明

例子:

(1)UDP是无连接的,不可靠,但是效率更高

​ TCP是有链接的,是可靠的,效率相对UDP更差

(2)UDP是面向数据报, 一次发一次收

​ TCP面向字节流 ,多次发,多次收

基于UDP和TCP的程序,既可以发也可以收,叫做全双工

(3)UDP没有发送缓冲区,只有接收缓冲区

​ TCP即有发送缓冲区,也有接收缓冲区

(4)UDP数据大小受限,TCP大小不限

(5)TCP提供了很多可靠传输的机制:

  1. 确认应答机制
  2. 超时重传机制
  3. 链接管理
  4. 流量控制
  5. 拥塞控制

提供的很多提高性能的机制

  1. 滑动窗口
  2. 延迟应答
  3. 捎带应答
3.传输层使用UDP协议发送大小不限的数据
4.传输层使用UDP协议,怎么保证安全可靠?

UDP协议

1. UDP特点

  • 无连接 : 知道对端的IP和端口号就直接进行传输,不需要建立连接

  • 不可靠 : 没有确认机制和重传机制,如果未能送达,UDP协议不会给应用层返回任何错误信息

  • 面向数据报 : 不能够灵活控制读写数据的次数和数量.发送端一次发送100个字节,接收端必须一次接受100个字节.不能循环10次,每次10个字节接受,

  • 大小受限不能超过64K.

2. UDP的缓冲区

  • UDP没有发送缓冲区
  • 有接受缓冲区,是为了接受多个来源的UDP包.不能保证收到的UDP的顺序和发送的顺序一致,而且如果缓冲区满了,后续到达的数据就会被丢弃

3. UDP传输大小

  1. UDP协议首部有一个16位的最大长度,也就是UDP能传输的最大数据长度为64K.超过了需要在应用层进行手动分包,多次发送.在接收端手动拼装.

4. 基于UDP的应用层协议

  • NFS : 网络文件共享协议
  • TFTP : 简单文件传输协议
  • DHCP : 动态主机配置协议
  • BOOTP : 启动协议
  • DNS : 域名解析协议

TCP协议

在这里插入图片描述

协议段格式说明:

  • 源/目的端口号 : 表示数据从哪个进程来,到哪个进程去;
  • 32位序号,32位确认号 : 用于确认发送的数据报是否正确,或者用于去重
  • 4位TCP报头 : 表示TCP头部有多少个32位bit(有多少个4字节)
  • 紧急URG:仅当URG=1时,表明紧急指针字段才有效,告诉系统报文中有紧急数据
  • 确认ACK:仅当ACK=1时,确认字段好才有效,TCP规定连接建立后,所有报文的传输都必须把ACK置为1;
  • 推送PSH:当两个应用进程进行交互式通信时,有时在一端的应用进程希望在键入一个命令之后立刻就能收到对方的响应,这个时候就将PSH=1;
  • 复位RST:当RST=1,表明TCP链接中出现严重差错。必须释放链接,然后再重新建立链接;
  • 同步SYN:当链接建立的时候用来同步序号。当SYN=1,ACK为0的时候,表明这个是请求链接报文,如果同意链接,则响应报文中应该使SYN=1,ACK=1;
  • 终止FIN:用于释放链接,当FIN=1,表明发送方数据已经发送完毕。并且要求释放。
  • 窗口大小:占两个字节,指的是发送本报文的一方的接受窗口。用于调整发送方的滑动窗口大小,从而调节TCP链接数据传输速度。保证接收方的 接受缓冲区不会溢出。

1. TCP原理/机制

1. 确认应答(ACK)机制 (安全机制)

在这里插入图片描述

发送数据时的编号,1-1000个字节存储在TCP 32 位序号 字段

应答形式:下一个是多少,将接受的数据序号最大值+1。接收到1000,应答为1001

应答的编号保存在TCP的 32位确认序号 字段

2. 超时重传机制(安全机制)
  1. 发送端发送的数据超过了一定时间间隔,没有收到确认应答的数据报.表示发送的数据可能丢包,所以要重新发送

    • 超时时间如何确定?

      ​ 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”. 但是这个时间的长短, 随着网络环境的不同, 是有差异的. 如果超时时间设的太长, 会影响整体的重传效率; 如果超时时间设的太短, 有可能会频繁发送重复的包;

      TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个最大超时时间.

      ​ Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时 重发的超时时间都是500ms的指数倍. 如果重发一次之后, 仍然得不到应答, 等待 2’*'500ms 后再进行重传. 如果仍然得不到应答, 等待 4**500ms 进行重传. 依次类推, 以指数形式递增. 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

    • 丢包的可能

      1. 发送的数据报丢包
      2. 确认应答的数据报丢包

      重复发送了很多重复包,可以在接收缓冲区使用序列号进行去重

3. 连接管理机制

在这里插入图片描述

链接:客户端和服务端.对每一段来说,保持一个本端到对端的链接状态(链接是有方向的)

  1. 建立连接(三次握手)

    建立客户端到服务端的链接(链接转台保存在客户端)

    建立服务端到客户端的链接(链接转台保存在服务端)

    1. 客户端发送syn数据报到服务端,申请建立客户端到服务端的链接

    2. 服务端返回syn+ack给客户端

      ack是对第一次syn的应答

      syn是申请建立服务端到客户端的链接

      客户端接受到该数据报,建立客户端到服务端的链接.

    3. 客户端返回ack给服务端

      ack是对上一步syn的应答.

  2. 断开连接(四次挥手)

在这里插入图片描述

  1. 客户端发送fin到服务端,申请关闭连接(客户端到服务端的链接),客户端状态进入FIN_WAIT_1(终止等待1)

  2. 服务端自动返回响应ack给客户端,服务端状态变为CLOSE_WAIT(关闭等待)

    ack是对第一次fin的应答

    ack的返回是操作系统实现TCP协议栈的时候默认的机制.系统自动返回

    ​ 此时客户端到服务器的链接就已经断开,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依旧要接受。

  3. 客户端收到服务端的ACK后,此时客户端进入FIN_WAIT_2(终止等待2)状态等待服务器发送完数据后的FIN

  4. 服务端等待自己数据发送完成后接着发送fin到客户端,申请关闭链接(服务端到客户端的链接),客户端接收到该数据报,状态置为time_wait

    程序手动调用close关闭连接,(发送fin)

  5. 客户端返回给服务端ack

    ack是对第二次fin的应答

面试题:
  • 为什么是四次挥手?不能是三次,五次 | 为什么不能合并为三次握手

​ 因为第二次挥手(ACK)是系统自动返回,第三次时程序手动调用close()然后发送fin给客户端(可以在程序关闭前,完成释放资源的前置操作)

​ 建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。

​ 而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

  • 第三次挥手后,客户端接受到fin,为什么不能置为关闭状态,而是要等待2MSL才能关闭?

在这里插入图片描述

MSL(Maximum Segment Lifetime) 最大报文生存时间 TCP允许不同的实现设置不同的MSL值.

第一, 是为了保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能会丢失

  1. 从服务器看,服务器已经发送了ACK 和 FIN(表示已经发送完数据)请求断开。
  2. 但是客户端没有回应。只能是发送的FIN没有被客户端收到。所以服务器会重新发送一次。
  3. 如果客户端在这个2MSL时间段内,收到这个重新发送的Fin报文,就会给出回应报文,并且会重启2MSL计时器。

第二 ,为了防止遇到三次握手中的,已经失效的了解请求报文段出现在本链接中。客户端发送完最后一个确认报之后,在这2MSL之间,滞留在网络中的数据报,此次TCP链接中的所有报文都将会在网络中消失。

就能保证两个传输方向上的上还没有被接受或者迟到的报文段都已经消失(否则服务器立即重启,可能会收到上一个进程迟到的数据,导致发生数据冲突)

  • 服务端出现大量的close_wait状态,是什么意思,怎么解决

    是因为服务端没有正确关闭调用close方法进行关闭链接

4.滑动窗口(提高效率)

如果使用串行的方法

在这里插入图片描述

​ 每次发送一个数据段就需要接受一个ack才能继续发送下一个数据段。在网络状况较差的时候,用于数据往返的时间就会很长。从而影响效率。

​ 所以我们可以同时发送多个数据报,同时接受多个响应的ack,(本质为将多个段的等待时间进行重叠)从而提高效率

在这里插入图片描述

  • 窗口大小指的是:无需等待应答就可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个数据段)。在发送这四个数据段的时候不用等待任何ACK就可以持续发送。
  • 当收到第一个ACK之后,滑动窗口就可以向后滑动,继续发送第五个段的数据。以此类推
  • 操作系统内核为了维护这个滑动窗口,开辟了发送缓冲区来记录当前还有哪些数据没有应答,只有确认应答过的数据才能从缓冲区删除。
  • 窗口越大,网络吞吐量就越高
1.情况一:数据报已经抵达,ACK丢失

在这里插入图片描述

​ 基于TCP协议的确认应答机制。如果在发送1-1000的响应ACK丢失,客户端没能接收到1-1000的响应ACK,但是在后续的ack响应中可以进行确认。

​ 如果能接受到后续响应,就代表着之前的数据报也是正常接受了。

2. 数据在发送途中丢失

在这里插入图片描述

​ 当数据报1001-2000在发送给接收端的时候丢失,基于确认应答机制.接收端在1001-2000没收到之前,会一直发送1001的ack.在发送端连续三次收到1001的ack之后.会将1001-2000的数据报重新发送.

​ 此时如果接收端收到1001-2000的报文段,再次返回的ACK就是7001,因为在接受缓存区中.2001-7000的包已经正常到达,被放在接受端的接受缓冲区了

这种机制被称为高速重发控制

5.流量控制(安全机制)接受端的安全

​ 接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端 继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.

TCP根据接收端的处理能力,来控制发送端的发送速度(就是调整滑动窗口的大小),这个机制叫做流量控制.

TCP报文的窗口大小字段,就保存了接受缓冲区的剩余大小.通过ACK通知发送端

  • 接受端发现自己的缓冲区快满了,就是将窗口大小设置成一个更小的值给发送端.发送端接收到之后,就会调整自己滑动窗口的大小.减慢自己的发送速度
  • 如果接收端的缓冲区满了,就会将窗口置为0,此时发送方不在发送数据,但是会定期发送一个窗口探测的数据段,使得接收端将目前的窗口大小进行调整

TCP首部4位首部选项中,包含了个窗口扩大因子M,实际窗口的大小值为,将窗口字段的值左移M位

6.拥塞控制(安全控制)发送端的安全

在不清楚当前网络状况的状态下,发送大量数据,可能会造成拥堵的网络状况更糟

所以TCP引入了慢启动机制.

img

拥塞窗口:cwnd

发送窗口:swnd

慢开始门限(阈值):ssthresh

  1. 慢开始阶段:cwnd < ssthresh

发送开始的时候,我们将拥塞窗口的大小设置为1,每次收到ACK应答的时候,就将拥塞窗口的大小+1.然后开始下一轮发送。

​ 此时发送方可以发送2个报文段,当接收方接收到这两个报文段确认报文ack之后,就将拥塞窗口的值从2变为4.此时能发送4个报文段,当接收方接收到这4个报文段的时候。将拥塞窗口+4变为8.以此类推直到 >=

当拥塞窗口增长到慢开始门限值的时候。就进入到第二阶段,使用拥塞避免算法

  1. 此时每个传输轮次,拥塞窗口cwnd的值只能+1,而不是想慢开始算法一样指数级别增长,当经过16+1+1.。。到达24的时候。

    此时发送的24个报文段丢失了4个报文段。接收方只能接受到20个报文段。给发送方回复了20个报文段。一段时间后,丢失的4个报文段重传计时器超时,发送方判断出现了拥塞。此时更改拥塞窗口cwnd的值为1,和慢开始门限ssthresh为 发生拥塞的拥塞窗口cwnd的一半为12。

7.延迟应答(提高效率)

如果接受到数据的主机立即返回ACK应答的话,处理端速度较快。这个时候返回的窗口比较小。在下次报文的传输到达之前接收端缓冲区没有报文进行处理。对于效率是一种很大的浪费。

采用延迟应答的话,接收端此时返回的流量大小会更大。网络数据传输的吞吐量会更大。

8.捎带应答(提高效率)

无论那一端(客户端还是服务端),需要主动发送的数据包可以和在接受数报包返回的ack数据报合并为1个。

类似于,tcp三次握手中,第二次合并syn和ack的数据包
在这里插入图片描述

9.粘包问题

粘包问题产生的原因:没有明确好的边界。

解决方法:在应用层读取多组数据时,一定要规定好一个业务的数据格式。

2.基于TCP协议的应用层协议

  • SMTP:

​ SMTP是一种提供可靠且有效的电子邮件传输的协议

  • telnet:

​ 是Internet远程登录服务的标准协议和主要方式

  • HTTP:

    ​ HTTP (HyperText Transfer Protocol 超文本传输协议) 基于 TCP,使用端口号 80 或 8080。

  • HTTPS:

    HTTPS (全称:Hyper Text Transfer Protocol over SecureSocket Layer),在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入SSL,HTTPS 的安全基础是 SSL,

  • FTP:

​ (File Transfer Protocol 文件传输协议) 基于 TCP,使用端口号 20(数据)和 21(控制)。它的主要功能是减少或消除在不同操作系统下处理文件的不兼容性,以达到便捷高效的文件传输效果。

FTP 只提供文件传输的基本服务,它采用 客户端—服务器 的方式,一个 FTP 服务器可同时为多个客户端提供服务。

在进行文件传输时,FTP 的客户端和服务器之间会建立两个 TCP 连接:21 号端口建立控制连接,20 号端口建立数据连接。

FTP 的传输有两种方式:ASCII 传输模式和二进制数据传输模式。

  • SSH

    ​ SSH 为 [Secure Shell](https://baike.baidu.com/item/Secure Shell) 的缩写,由 IETF 的网络小组(Network Working Group)所制定;SSH 为建立在应用层基础上的安全协议。SSH 是较可靠,专为远程登录会话和其他网络服务提供安全性的协议

网络层概念

基本概念:

主机:配有IP地址,但是不进行路由控制的设备;

路由器:配有IP地址,又能进行路由控制;

节点:直接和路由器的统称;

IP协议

在这里插入图片描述

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值