网络原理之TCP_IP

目录

应用层重点协议

传输层重点协议

1.UDP协议

(一)UDP协议段格式

 (二)UDP的特点

无连接

不可靠传输

面向数据报

全双工

缓冲区

大小受限

(三)基于UDP的应用层协议

(四)面试题

2.TCP协议 

(一)TCP协议段格式

 (二)TCP的特点

有连接

可靠传输

面向字节流

缓冲区

全双工

粘包问题

异常情况

(三)基于TCP应用层协议

​编辑网络层重点协议

IP协议

数据链路层重点协议

面试题


 

我们知道TCP/IP五层(或四层)模型包括:

  • 应用层
  • 传输层
  • 网络层
  • 数据链路层
  • 物理层

网络原理之TCP_IP_第1张图片

网络原理之TCP_IP_第2张图片

那网络传输是怎样具体展开的呢~

举个例子(发送方“封装”)(接收方要“分用”)

网络原理之TCP_IP_第3张图片 网络原理之TCP_IP_第4张图片

网络原理之TCP_IP_第5张图片

网络原理之TCP_IP_第6张图片

网络原理之TCP_IP_第7张图片

网络原理之TCP_IP_第8张图片

网络原理之TCP_IP_第9张图片

网络原理之TCP_IP_第10张图片

网络原理之TCP_IP_第11张图片

下面我们就来学习各个层的重点协议~~ 

 应用层重点协议

网络原理之TCP_IP_第12张图片

网络原理之TCP_IP_第13张图片

传输层重点协议

1.UDP协议

(一)UDP协议段格式

网络原理之TCP_IP_第14张图片

  • 16位UDP长度,表示整个数据报(UDP首部+UDP数据)的最大长度
  • 如果校验和出错,就会直接丢弃        
 (二)UDP的特点
无连接

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

不可靠传输

没有任何安全机制,发送端发送数据报后,如果遇到网络故障该段无法发送过去,UDP协议层也不会给应用层返回任何错误信息

面向数据报

应用层发给UDP多长的报文,UDP原样发送,既不会拆分也不会合并

全双工

UDP的socket既能读也能写

缓冲区

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

UDP没有真正意义上的 发送缓冲区。发送的数据会直接交给内核,由内核将数据传给网络层协议 进行后续的传输动作;

UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一 致;如果缓冲区满了,再到达的UDP数据就会被丢弃;

大小受限

UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。

(三)基于UDP的应用层协议
  • NFS:网络文件系统
  • TFTP:简单文件传输协议
  • DHCP:动态主机配置协议
  • BOOTP:启动协议(用于无盘设备启动)
  • DNS:域名解析协议

当然,也包括你自己写UDP程序时自定义的应用层协议。

(四)面试题

1. UDP本身是无连接,不可靠,面向数据报的协议,如果要基于传输层UDP协议,来实现一个可靠传 输,应该如何设计?

2. UDP大小是受限的,如果要基于传输层UDP协议,传输超过64K的数据,应该如何设计? 

以上两个问题答案类似,都可以参考TCP的可靠性机制在应用层实现类似的逻辑:

例如:

  • 引入序列号,保证数据顺序;
  • 引入确认应答,确保对端收到了数据;
  • 引入超时重传,如果隔一段时间没有应答,就重发数据;
  • …… 

2.TCP协议 

(一)TCP协议段格式

网络原理之TCP_IP_第15张图片

 (二)TCP的特点
有连接

在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接

网络原理之TCP_IP_第16张图片

那啥叫断开连接呢? 

A和B把自己存储的连接信息(数据结构)删了,连接就是断开了~~

三次握手:

网络原理之TCP_IP_第17张图片

网络原理之TCP_IP_第18张图片

建立连接阶段,主要认识两个状态:

1.LISTEN 服务器的状态

表示服务器已经准备就绪,随时可以跟客户端来建立连接,相当于手机开机,信号良好,随时可以有人来打电话~~

2.ESTABLISHED 客户端和服务器都有

表示连接建立完成,接下来就可以正常通信了,相当于电话拨过去,对方接通了~~ 

网络原理之TCP_IP_第19张图片  

四次挥手:

网络原理之TCP_IP_第20张图片

 网络原理之TCP_IP_第21张图片

 断开连接阶段,主要认识两个状态:

1.TIME_WAIT

TIME_WAIT表示要保持当前的TCP连接状态不要立即就释放~

为什么不要连接释放呢?

网络原理之TCP_IP_第22张图片

TIME_WAIT如果等待了一段时间后也没收到重传的FIN,此时就认为,最后的一个ACK没丢,于是就彻底的释放连接了~

网络原理之TCP_IP_第23张图片

2.CLOSE_WAIT 出现在被动发起断开连接的一方

建立连接一定是客户端主动发起请求的,断开连接,可能是客户端主动发起,也可能是服务器主动发起~

CLOSE_WAIT表示等待关闭,等待调用close方法关闭socket

有连接和确认应答的区别:

网络原理之TCP_IP_第24张图片

可靠传输

网络原理之TCP_IP_第25张图片

确认应答机制

网络原理之TCP_IP_第26张图片

网络后发先至这个现象是客观存在的,如何解决这个问题呢?

方法很简单,给传输的数据和应答报文,都进行编号就可以了!!!

TCP将每个字节的数据都进行了编号。即为序列号。

网络原理之TCP_IP_第27张图片

每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。

超时重传机制

主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发;

如果一直丢包,主机A会一直重传吗?

答案是不会的~

网络原理之TCP_IP_第28张图片

网络原理之TCP_IP_第29张图片

网络原理之TCP_IP_第30张图片

但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了;

网络原理之TCP_IP_第31张图片

由于主机B返回的确认应答因网络堵塞等原因在传输的途中丢失,没有到达主机A,主机A会等待一段时间,若在特定时间间隔始终未能收到确认应答,主机A会对此数据进行重发,此时,主机B将第二次发送已接收数据的确认应答,由于主机B已经收到过1~1000的数据,当再有重复数据送达时它会放弃~~

滑动窗口机制

刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送 下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候

既然这样一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多 个段的等待时间重叠在一起了)

网络原理之TCP_IP_第32张图片

 当批量发送了窗口大小的这些数据之后,发送方就要等待ACK了

那么啥时候继续往下发送呢?发送方不是等待所有的ack到达才继续往下发,而是到了一个ack,就继续往下发一条...

如上图的例子,那么我们等待的ack始终是4条~

 那么如果出现了丢包,如何进行重传?这里分两种情况讨论。

情况一、数据包丢了

网络原理之TCP_IP_第33张图片

网络原理之TCP_IP_第34张图片

网络原理之TCP_IP_第35张图片

情况二、ack丢了

网络原理之TCP_IP_第36张图片 流量控制机制

这是一种干预发送窗口大小的机制

滑动窗口越大,传输效率越高(一份时间,等待的ack越多)

但是,窗口也不能无限的大~否则会造成以下的问题:

1.完全不等ack,可靠性能否保障画上问号

2.窗口越大,也会消耗大量的系统资源

3.发送速度太快,接收方处理不过来,发了也白发

接收方的处理能力,就是一个很重要的约束依据

发送方发数据的速度,不能超过接收方的处理能力

流量控制要做的工作就是这个,根据接收方的处理能力,协调发送方的发送效率

那如何衡量接收方的处理能力?

其实可以直接看接收方接收缓冲区的剩余大小~

当窗口大小为0,发送方就要暂停发送,暂停发送的等待过程中,会给B定期发送窗口探测报文,这个报文不携带具体的业务数据,只是为了触发ack查询窗口大小~~

网络原理之TCP_IP_第37张图片

网络原理之TCP_IP_第38张图片

网络原理之TCP_IP_第39张图片

网络原理之TCP_IP_第40张图片

延时应答机制

网络原理之TCP_IP_第41张图片

网络原理之TCP_IP_第42张图片

 网络原理之TCP_IP_第43张图片

面向字节流
缓冲区

创建一个TCP的socket,同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

网络原理之TCP_IP_第44张图片

网络原理之TCP_IP_第45张图片

前面我们说过~网络上的传输可能后发先至

TCP使用这个接收缓冲区,对接收的数据进行重新排序,使应用程序read到的数据是保证有序的(和发送顺序一致)

全双工

既可以读数据,也可以写数据。

粘包问题

首先要明确,粘包问题中的 "包" ,是指的应用层的数据包。

在TCP的协议头中,没有如同UDP一样的 "报文长度" 这样的字段,但是有一个序号这样的字 段。

站在传输层的角度,TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。

站在应用层的角度,看到的只是一串连续的字节数据。 

那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个 完整的应用层数据包。

那么如何避免粘包问题呢?

归根结底就是一句话,明确两个包之间的边界。

对于定长的包,保证每次都按固定大小读取即可;

就从缓冲区从头开始按sizeof()依次读取即可;

对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位 置;

对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定 的,只要保证分隔符不和正文冲突即可);

异常情况

网络原理之TCP_IP_第46张图片

网络原理之TCP_IP_第47张图片

(三)基于TCP应用层协议
  • HTTP
  • HTTPS
  • SSH
  • Telnet
  • FTP
  • SMTP
  • 当然,也包括你自己写TCP程序时自定义的应用层协议;

网络原理之TCP_IP_第48张图片网络层重点协议

IP协议

协议头格式如下:

网络原理之TCP_IP_第49张图片

4位版本号(version):指定IP协议的版本,对于IPv4来说,就是4。

4位头部长度(header length):IP头部的长度是多少个32bit,也就是 length * 4 的字节 数。4bit表示最大的数字是15,因此IP头部最大长度是60字节。

8位服务类型(Type Of Service):3位优先权字段(已经弃用),4位TOS字段,和1位保留 字段(必须置为0)。4位TOS分别表示:最小延时,最大吞吐量,最高可靠性,最小成本。 这四者相互冲突,只能选择一个。对于ssh/telnet这样的应用程序,最小延时比较重要;对于 ftp这样的程序,最大吞吐量比较重要。

16位总长度(total length):IP数据报整体占多少个字节。

16位标识(id):唯一的标识主机发送的报文。如果IP报文在数据链路层被分片了,那么每 一个片里面的这个id都是相同的。

16位头部校验和:使用CRC进行校验,来鉴别头部是否损坏。

32位源地址和32位目标地址:表示发送端和接收端。

网络原理之TCP_IP_第50张图片 举个例子:

网络原理之TCP_IP_第51张图片

 网络原理之TCP_IP_第52张图片

我们来想一个问题~如果IP地址不够用了怎么办?

1.动态分配IP地址。此时就可以省下一大批IP地址了,但是这个方案没有从根本上增加IP地址,只是提高了利用率,治标不治本~

2.NAT网络地址转换,本质是使用一个IP地址代表一批设备,使用端口号区分,能够大大提高IP地址的利用率

网络原理之TCP_IP_第53张图片

网络原理之TCP_IP_第54张图片

网络原理之TCP_IP_第55张图片

3.IPv6 (从根本解决IP不够用的问题)

使用16字节,表示IP地址,

网络原理之TCP_IP_第56张图片

特殊的IP地址:

  • 将IP地址中的主机地址全部设为0,就成为了网络号,代表这个局域网
  • 将IP地址中的主机地址全部设为1,就成为了广播地址,用于给同一个链路中相互连接的所有主机发送数据
  • 127.*的IP地址用于本机环回测试,通常是127.0.0.1
  • 本机环回主要用于本机到本机的网络通信,(系统内部为了性能,不会走网络的方式传输)

路由选择 

网络原理之TCP_IP_第57张图片

数据链路层重点协议

网络原理之TCP_IP_第58张图片

mac地址是6个字节的(比IPv4地址大很多)当前每个设备都有一个唯一的mac地址,不是动态分配的,而是网卡出厂的时候设置好的

网络原理之TCP_IP_第59张图片

网络原理之TCP_IP_第60张图片

网络原理之TCP_IP_第61张图片

MTU :

网络原理之TCP_IP_第62张图片

面试题

关于网络原理这块知识点,会有一个常考的面试题:

在浏览器输入www.baidu.com并按下回车后,到最终页面展示,涉及了许多网络原理和技术,以下是整个过程的简要步骤:

1. DNS解析:
   - 浏览器首先会将输入的URL解析成IP地址。这个过程称为DNS解析,它通过查询域名系统(DNS)来找到与www.baidu.com相关联的IP地址。

2. 建立TCP连接:
   - 一旦浏览器知道了目标服务器的IP地址,它会尝试与该服务器建立TCP连接。这是通过三次握手过程完成的,包括客户端向服务器发送连接请求,服务器回复确认,然后客户端再次确认。

3. 发起HTTP请求:
   - 一旦建立了TCP连接,浏览器将发起一个HTTP请求,以获取与www.baidu.com关联的网页。这个请求包含了要获取的页面信息,以及其他相关的HTTP头部信息。

4. 服务器处理请求:
   - 目标服务器(www.baidu.com)收到浏览器的请求后,会根据请求的内容和服务器上的配置来处理请求。通常,服务器会生成响应,包括网页内容、状态码和其他HTTP头部信息。

5. 服务器发送HTTP响应:
   - 一旦服务器处理完请求,它会将HTTP响应发送回客户端(浏览器)。这个响应包括HTTP状态码,例如200 OK表示成功,以及请求的网页内容。

6. 浏览器渲染页面:
   - 浏览器接收到HTTP响应后,会解析HTML、CSS和JavaScript代码,然后渲染页面。这包括将HTML结构转化为可见的网页,并加载和执行JavaScript代码以添加交互性和动态内容。

7. 页面展示:
   - 最终,浏览器将完整的网页渲染出来,并将其呈现在用户的屏幕上,用户可以看到和与网页交互。

你可能感兴趣的:(网络原理,网络,tcp/ip,网络协议)