TCP/IP模型原理(理论)

发布于:2024-07-02 ⋅ 阅读:(12) ⋅ 点赞:(0)

1. 网络模型简介

学习计算机网络,本质上就是在学习每一层的各种协议。
请添加图片描述

2. 应用层

所谓应用层,相当于我们用的软件。程序员写代码的地方,其实就是应用层。

2.1 URL

URL的全称是Uniform Resource Locator,即全球统一资源定位点
在这里插入图片描述
如上所示:每个“网页”都有一个唯一的路径(URL),我们可以通过唯一的路径(URL),去访问相应的内容。

2.1.1 urlencode和urldecode

对于一些特殊字符,像/+?等字符,已经被url当作特殊意义理解了。因此这些字符不能随意出现。
比如说:某个参数中需要带有这些特殊字符,就必须先对特殊字符进行转义。

转义的规则:
将需要转码的字符转为16进制,然后从右到左,取4位(不足4位直接处理),每2位做一位,前面加上%,编码成%XY格式;

如: c++ 会被转义成 c%2B%2B

可以使用编码解码的工具来了解一下URL字符的转义规则:
url编码解码工具

2.2 HTTP协议

2.2.1 HTTP协议格式

在这里插入图片描述

  • 首行:[方法]+[url]+[版本]
  • Header:请求的属性,冒号分隔的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束。
  • Body:空行的内容都是Body。Body允许为空字符串。如果Body存在,则在Header中会有一个Content-Length属性来标识Body的长度。

在这里插入图片描述

该图片是浏览器访问www.baidu.com时,抓到的报文。大家看一下它的大概结构。


方法 说明 支持的HTTP协议版本
GET 获取资源 1.0、1.1
POST 传输实体主体 1.0、1.1
PUT 传输文件 1.0、1.1
HEAD 获得报文首部 1.0、1.1
DELETE 删除文件 1.0、1.1
OPTIONS 询问支持的方法 1.1
TRACE 追踪路径 1.1
CONNECT 要求采用隧道协议连接代理 1.1
LINK 建立和资源之间的联系 1.0
GET 断开连接关系 1.0

常见的Header:

  • Content-Type:数据类型(text/htlm)等
  • Content-Length:Body的长度
  • Host:客户端告知服务器,所请求的资源在哪个主机哪个端口上。
  • User-Agent:声明用户的操作系统和浏览器版本信息。
  • referer:当前页面是从哪个页面跳转过来的。
  • location:搭配3xx状态码使用,告诉客户端接下来要去哪里访问。
  • Cookie:用于在客户端存储少量信息,通常用于实现会话(session)的功能。

在这里插入图片描述
最常见的状态码:

  • 200(OK)成功的意思
  • 404(Not Found):请求页面失败
  • 302(Redirect,重定向):重定向到另一个页面,跳转。

2.2.2 HTTP问题

GET和POST方法可以传参吗?
其中GET方法通过URL进行传参,参数受限制,不安全。
POST方法也支持参数提交,采用请求正文的方式提交参数。更私密。

一个巨大的页面是会包含非常多的元素的,那么它们都是怎么传输的?
短链接(http/1.0):一次请求响应一个资源,关闭连接,短链接。
长链接(http/1.1):建立一个TCP连接,发送和返回多个http的请求和回复。

cookie是什么?
http协议默认是无状态的,cookie可以对登录的用户会话保持功能。
工作原理:

  1. 浏览器输入账号密码并且提交给服务器。
  2. 服务器收到之后,验证用户的合法性,成功后会产生一个session id由服务器同意管理分配。
  3. 然后将session id 打包成 set-Cookie:session消息,发送给浏览器。
  4. 浏览器接收后,会形成cookie文件,当再次访问时会携带这个cookie文件。
  5. 服务器收到这个cookie文件后,如果查询到这个session后,会自动维护该用户的登陆状态。用户不必再次输入账号和密码。

2.2.3 HTTPS

HTTPS协议只需要了解安全问题就可以了。
HTTPS加密过程详解

3 传输层

负责数据从发送端到接收端的过程。

3.1 端口号

端口号标识了一个主机上进行通信的不同应用程序;
在这里插入图片描述
在TCP/IP协议中,用“源IP、源端口、目的IP、目的端口、协议号”这五元组来标识一个通信(可以使用net stat -n查看);


端口号范围划分
0~1023:知名端口号,HTTP,FTP,SSH等。
1024~65535:OS动态分配的端口号。客户端程序的端口号,就是由OS从这个范围分配的。
知名端口号:

  • ssh 服务器,22
  • ftp 服务器,21
  • telnet 服务器,23
  • http服务器,80
  • https服务器,443

执行该命令,可看到知名端口号:

cat /etc/services

3.2 udp

3.2.1 udp协议帧格式

在这里插入图片描述

  • 16位udp长度,表示整个数据报(udp首部(8字节)+udp数据)的最大长度。
  • 如果校验和出错,直接丢弃。

3.2.2 udp特点

  • 无连接:知道对端的IP和端口号就直接进行传输,不需要建立连接;
  • 不可靠:没有确认机制,没有重传机制;如果因为网络故障该段无法发到对方,UDP协议层也不会给应用层返回任何错误信息。
  • 面向数据报:不能够灵活的控制读写数据的次数和数量。

什么叫做面向数据报呢?
应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并。
比如:使用UDP传输100个字节的数据:

  • 如果发送端调用一次sendto,发送100个字节,那么接收端也必须调用一次recvfrom接收100个字节;而不是循环调用10次recvfrom每次接收10个字节。

3.2.3 udp缓冲区

  • udp没有真正意义上的发送缓冲区,调用sendto会直接交给内核,由内核将数据传给网络层协议后进行后续的传输动作。
  • udp具有接收缓冲区。但是这个接收缓冲区不能保证收到的udp报的顺序和发送udp报的顺序一致;如果缓冲区满了,再到达的udp数据就会被丢弃;

udp的socket既能读,也能写,是全双工的。

3.2.4 注意

UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(2^16包含UDP首部)。
然鹅64K并不大,如果需要传输大于64K的数据,就需要在应用层手动分包,多次发送,并在接收端手动拼装。


基于UDP的协议有:
在这里插入图片描述

3.3 tcp协议

“传输控制协议(Transmission Control Protocol)”

3.3.1 tcp协议段格式

在这里插入图片描述

  • 32位序列号/确认号:通信过程中,需要以此序号为标志,通信的先后顺序。
  • 4位TCP报头长度:表示该TCP头部有多少个32位bit(有多少个4字节);所以TCP头部最大为15*4=60字节。
  • 6位标志位:
    • URG:紧急指针是否有效
    • ACK:确认序号是否有效
    • PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走。
    • RST:对方要求重新建立连接;称为复位报文段
    • SYN:请求建立连接(同步报文段)。
    • FIN:通知对方,本端要关闭了(结束报文段)
  • 16位窗口大小:用于通知接收缓冲区的接收能力。
  • 16位校验和:发送端填充,CRC校验。接收端校验不通过,则认为数据有问题。校验部分(首部+数据部分)。
  • 16位紧急指针:标识哪部分是紧急数据。
  • 40字节头部选项:暂时忽略。

3.3.2 确认应答机制

TCP将每个字节(字节流)的数据都进行了编号。即为序列号。序列号的意思就是我发送到了哪个序号。然后每个报文都要有确认号a,确认机制。意义是:我已经收到了a-1,下次你从a开始发。

3.3.3 超时重传机制

无差错时:
在这里插入图片描述
停止等待协议:每发送一个报文就停止等待,只有收到该报文的确认序号才发送下一个。若迟迟没有收到,则进行重传。
有差错时:确认丢失和确认迟到
在这里插入图片描述
通过上述的确认和重传机制,可以实现在不可靠的网络上实现可靠的通信。
上述的可靠协议常称为:自动重传请求(ARQ)。


连续ARQ协议:
上述方法发1等1信道利用率低,下面介绍基于滑动窗口的方法,可以达到流水线的效果:
发送窗口可以连续发送窗口大小个数据,而不需要等待对方的确认。
在这里插入图片描述
接收方采用累计确认的方式。接收方不需要对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认
优点:容易实现,即使丢失也不必重传。
缺点:不能向发送方反应接收方已经正确收到所有分组的信息。

3.3.4 连接管理

在这里插入图片描述
服务器端转化:

  • [CLOSED->LISTEN]:服务器端调用listen后进入LISTEN状态,等待客户端连接;
  • [LISTEN->SYN_RCVD]:一旦监听到连接请求(同步报文段),就将该连接放入内核等待队列中,并向客户端发送SYN确认报文。
  • [SYN_RCVD->ESTABLISHED]:服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,可以进行读写数据了。
  • [ESTABLISHED->CLOSE_WAIT]:当客户端主动关闭连接(调用close),服务器会收到结束报文段,服务器返回确认报文段并进入CLOSE_WAIT;
  • [CLOSE_WAIT->LAST_ACK]:进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据);当服务器真正调用close关闭连接时,会向客户端发送FIN,此时服务器进入LAST_ACK状态,等待最后一个ACK到来(这个是客服端确认收到了FIN)。
  • [LAST_ACK->CLOSED]:服务器受到了对FIN的ACK,彻底关闭连接。

客户端状态转化:

  • [CLOSED->SYN_SENT]:客户端调用connect,发送同步报文段。
  • [SYN_SENT->ESTABLISHED]:connect调用成功,则进入ESTABLISHED状态,开始读写数据。
  • [ESTABLISHED->FIN_WAIT_1]:客户端主动调用close时,向服务器发送结束报文段,同时进入
    FIN_WAIT_1;
  • [FIN_WAIT_1->FIN_WAIT_2]:客户端收到服务器对结束报文段的确认,则进入FIN_WAIT_2,开始等待服务器的结束报文段;
  • [FIN_WAIT_2->TIME_WAIT]:客户端收到服务器发来的结束报文段,进入TIME_WAIT,并发出LAST_ACK;
  • [TIME_WAIT->CLOSED]:客户端要等待一个2MSL(Max Segment Life,报文最大生存时间),才会进入CLOSED状态。

3.3.5 理解TIME_WAIT状态

如果我们立马启动服务器,然后Ctrl-C使服务器终止,马上再运行server,结果是:
在这里插入图片描述
因为:虽然server的程序中止了,但TCP协议层的连接并没有完全断开,因此不能再次监听同样的server端口。
在这里插入图片描述

  • TCP协议规定,主动关闭连接的一方要处于TIME_WAIT状态,等待两个MSL的事件后才能够回到CLOSED状态。
  • 我们使用CTRL-C终止了server,所以server是主动关闭连接的一方,在TIME_WAIT期间仍然不能再次监听同样的server端口;
  • MSL在RFC1122中规定为2分钟,但是具体实现跟OS有关,在Centos7默认为60s
通过该命令查看MSL的值
cat /proc/sys/net/ipv4/tcp_fin_timeout

3.4 传输层问题

1.一个进程可否bind多个端口号?
一个进程可以bind多个不同的端口号,可能会实现不同的功能。
2. 一个端口号是否可以被多个进程bind?
不可以,因为socket是唯一识别端到端的标识符,多个进程bind一个端口号,会导致这个消息不知道发给谁!
3. write,read,recv,send…是拷贝函数?
对,本质上其实就是拷贝函数,把数据从进程中拷贝到发送缓冲区上。
4. 三次握手过程?
更详细的内容在这里
5. 四次挥手过程?
更详细的内容在这里
6. 为什么TIME_WAIT的时间是2MSL?
因为MSL是最大报文生存时间,因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启,可能会收到来自上一个进程的迟到的数据,但是这种数据很可能是错误的!);同时也是在理论上保证最后一个报文的可靠到达(假设最后一个ACK丢失,那么服务器会再重发一个FIN,这时虽然客户端的进程不在了,但是TCP还在,仍然可以重发LAST_ACK);

7. 如何使用UDP实现可靠传输?

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

3.5 粘包问题

  • 首先要明确,粘包问题中的”包“,是指应用层的数据包。
  • 在TCP协议头中,没有如同UDP一样的”报文长度字段“,但是有序号这样的字段。
  • 站在传输层角度,TCP是一个一个报文过来的,按照序号排好放在缓冲区中。
  • 站在应用层角度看,看到的只是一串连续的字节数据。

因此应用程序看到一串连续的字节数据,不知道从哪里开始那里结束,这个就是粘包问题。
如何避免粘包问题呢?一句话:明确两个包之间的边界。

  • 对于定长的包,每次保证固定大小读取即可;(Request结构,就是定长的)
  • 对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而知道包的结束位置。
  • 对于边长包,可以在包和包之间使用明确的分隔符(应用层协议,程序员自己定,只需要保证分隔符不和正文冲突即可)。

对于UDP来说是否有粘包问题呢?

  • UDP如果还没有上层交付数据,UDP的报文长度仍然存在。同时,UDP是一个一个把数据交付给应用层的,有很明确的数据边界。
  • 站在应用层的角度,使用UDP,要么收到完整的UDP报文,要么不收,不会出现”半个的情况“。

3.6 TCP异常

进程终止:进程终止会释放文件描述符,仍然可以发送FIN。和正常关闭没区别。
机器重启:和进程终止的情况相同。
机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行reset。及时没有写入操作,TCP自己内置了一个保活定时器,会定期询问对方是否还在。如果对方不在,也会把连接释放。

3.7 TCP优势

可靠性:

  • 校验和
  • 序列号
  • 确认应答
  • 超时重发
  • 连接管理
  • 流量控制
  • 拥塞控制

提高性能:

  • 滑动窗口
  • 快速重传
  • 延迟应答
  • 捎带应答

其他:

  • 定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等)。

3.8 基于TCP的应用层协议

HTTP、HTTPS、SSH、Telent、FTP、SMTP,也包括自己写TCP程序时自定义的应用层协议。

4 网络层

主机:配有IP地址,但是不进行路由控制的设备。
路由器:配有IP地址,又能进行路由控制
节点:主机和路由器的统称。

4.1 IP协议格式

在这里插入图片描述

  • 4位版本号(version):指定IP协议的版本,对于IPv4来说,就是4。
  • 4位头部长度(header length):单位4字节。最大15*4 = 60字节。
  • 8位服务类型(Type Of Service):3位优先权字段(弃用),4位TOS字段,和1位保留字段(必须置为0).4位TOS分别表示:最小延时,最大吞吐量,最高可靠性,最小成本。这四个相互冲突,只能选择一个。
  • 16位总长度(total length):IP数据报整体占多少字节。
  • 16位标识(id):唯一的标识主机发送的报文。如果IP报文在数据链路层被分片了,那么每一个片里面的这个id都是相同的。
  • 3位标志字段:第一位保留。第二位1表示禁止分片,如果这时报文长度超过MTU,IP模块就会丢弃报文。第三位表示”更多分片“,如果分片的话,最后一个分片置为1,其他是0.类似一个结束标志。
  • 13位分片偏移(framegament offset):是分片相对于原始IP报文开始处的偏移。其实就是在表示当前分片在原报文的哪个位置。实际偏移的字节数是这个值*8得到的。因此,除了最后一个报文外,其他报文长度必须是8的整数倍(不够填充)。
  • 8位生存时间(Time To Live,TTL):数据报到达目的地的最大报文跳数。(主要是防止路由循环)。
  • 8位协议:表示上层的协议类型
  • 16位头部校验和:使用CRC进行校验,来鉴别头部是否损坏。
  • 32位源地址和32位目的地址:标识位置。
  • 选项字段(不定长,最多40字节):略。

4.2 网段划分

IP地址分为两部分,网络号和主机号

  • 网络号:保证相互连接的两个网段具有不同的标识;
  • 主机号:同一个网段内,主机之间具有相同的网络号,但必须有不同的主机号。
  • 不同的子网其实就是把网络号相同的主机放在一起。
  • 如果在子网中新增一台主机,这台主机的网络号和子网一致,但是主机号必须不能和子网中的其他主机重复。

过去的划分方法:
在这里插入图片描述

  • A类:0.0.0.0~127.255.255.255
  • B类:128.0.0.0~191.255.255.255
  • C类:192.0.0.0~223.255.255.255
  • D类:224.0.0.0~239.255.255.255
  • E类:240.0.0.0~247.255.255.255

随着网络发展,这种不均衡的方式导致B类地址很快就分配完了,而A类缺还有很多。


针对这种情况新的划分方案CIDR(Classless Interdomain Routing):

  • 引入一个额外的子网掩码(subnet mask)来区分网络号和主机号;
  • 子网掩码也是一个32位的正整数,通常用一串”0“结尾;
  • 将IP地址和子网掩码进行”按位与“操作,得到的结果就是网络号;
  • 网络号和主机号的划分与这个地址是ABC类无关。

特殊IP地址

  • 将主机号全部设置为0,就成了网络号,代表整个局域网。
  • 将主机号全部设置为1,就成了广播地址,用于局域网中的所有主机发送数据包。
  • 127.*的IP地址用于本机环回(loop back)测试,通常是127.0.0.1。

4.2.1 DHCP

能够自动的给子网内新增主机节点分配IP地址,避免了手动管理IP的不方便。
一般的路由器带有DHCP功能。因此路由器也可以看作是一个DHCP服务器。

4.3 IP地址的数量限制

ipv4的地址只有40多亿,如何解决地址不够的问题?

  • 动态分配IP地址:只给接入网络的设备分配IP地址,因此同一个MAC地址的设备,每次接入互联网中,得到的IP地址不一定是相同的。
  • NAT技术(私有IP和共有IP来解决)。
  • IPv6技术

4.4 私有地址和公网IP地址

私有IP地址:

  • 10.*,前8位是网络号,共16,777,216个地址。
  • 172.16~172.31. 前12位是网络号,共1,048,576个地址
  • 192.168.*,前16位是网络号,共65536个地址。
    这个范围内的都是私有地址,其余的称为全局IP。
  1. 一个路由器可以配备两个IP地址,一个是WAN口IP,一个是LAN口IP(子网IP)。
  2. 路由器LAN口连接的主机,都从属于当前这个路由器的子网中。
  3. 不同的路由器,子网IP其实都是一样的(通常是192.168.1.1),子网内的主机IP地址不能重复,但是子网之间的IP地址就可以重复了。
  4. 每一个家用路由器,其实又作为运营商路由器的子网中的一个节点。这样的运营商路由器可能会有很多级,最外层的运营商路由器,WAN口IP就是公网IP了。
  5. 子网内的主机需要和外网进行通信时,路由器将IP首部中的IP地址进行替换(替换成WAN口IP),这样逐级替换,最终数据包中的IP地址称为一个公网IP。这种技术称为NAT(网络地址转换)。
  6. 如果我们希望自己的服务器程序能够在公网上被访问到,就需要一台具有外网的IP服务器。(因为192.地址别人访问不到)

4.5 路由生成算法和IP数据包传输的过程

5 数据链路层

以太网不是一种具体的网络,而是一种技术标准;既包含了数据链路层的内容,也包含了一些物理层的内容。规定了网络拓扑结构,访问控制方式,传输速率等;以太网时当前应用最广泛的局域网技术;和以太网并列的还有令牌环网,无线LAN等。

5.1 以太网帧格式

在这里插入图片描述

5.2 MAC地址

MAC地址用来识别数据链路层中相连的节点;长度为48位,及6个字节。一般用16进制数字加上冒号的形式来表示;mac地址一经出场就已经定了,通常是唯一的。

5.3 MTU(最大传送单元)

在数据链路中所传送的最大帧长度。

  • 以太网帧中的数据长度:46~1500字节;ARP数据包长度不够46字节,要在后面补填充位。
  • 最大值位1500是以太网的最大传输单元(MTU),不同网络有不同的MTU;
  • 如果一个数据包从以太网路由到拨号链路上,数据包长度大于拨号链路的MTU了,需要对数据包进行分片(fragmentation)

5.3.1 MTU对IP协议影响

由于数据链路层的MTU限制,对于较大的IP数据包要分包。

  • 将较大的IP包分成多个小包,并给每个小包打上标签;
  • 每个小包IP协议头的16位标识(id)都是相同的;
  • 每个小包的IP协议头的3个标志字段中,第二位是0,标识允许分片,第三位标识结束标记(当前是否是最后一个小包,是的话置为1,否则置为0);
  • 到达对端时再将这些小包,会按顺序重组,拼装到一起返回给传输层;
  • 一旦这个小包中的任意一个小包丢失,接收端的重组就会失败。但是IP层不会负责重传新数据;

5.3.2 MTU对UDP协议影响

  • 一旦UDP携带的数据超过1472(1500-20(IP首部)-8(UDP首部)),那么就会在网络层分成多个IP数据报。
  • 这多个IP数据包有任意一个丢失,都会引起接收端网络重组失败。那么这意味着,如果UDP数据报在网络层被分片,这个数据被丢失的概率大大增加。

5.3.3 MTU对TCP协议影响

  • TCP的一个数据包也不是无限大,还是受制于MTU。TCP单个数据报的最大消息长度,称为MSS(Max Segment Size);
  • TCP在建立过程中,通信双方会进行MSS协商。
  • 最理想的情况下,MSS的值正是在IP不会被分片处理的最大长度(这个长度仍然是受制于数据链路层的MTU)。
  • 双方在发送SYN的时候会在TCP头部写入自己能支持的MSS值。然后双方得知对方的MSS值后,选择较小的MSS。MSS的值在TCP首部的40字节变长选项中(kind=2);
输入 ifconfig 查看硬件地址和MTU

在这里插入图片描述

5.4 ARP协议

ARP协议是一个介于数据链路层和网络层之间的协议;

5.4.1 ARP的作用

ARP协议建立了主机 IP地址 和 MAC地址 的映射关系。

  • 在网络通讯时,源主机的应用程序知道目的主机的IP地址和端口号,却不知道目的主机的硬件地址;
  • 数据包首先是被网卡接收到再去处理上层协议的,如果接收到的数据包的硬件地址与本机不符,则直接丢弃;
  • 因此在通讯前必须获得目的主机的硬件地址;

5.4.2 ARP协议工作流程

在这里插入图片描述

  • 源主机发出ARP请求,询问”IP地址是192.168.0.1的主机硬件地址是多少“,并将这个请求广播到本地网段(以太网帧填FF:FF:FF:FF:FF:FF:FF:FF广播);
  • 目的主机接收到广播ARP请求,发现其中的IP地址与本机相符,则发送一个ARP应答数据包给源主机,将自己的硬件地址填写在应答包中;
arp -a 查看arp缓存表

每台主机都维护一个ARP缓存表,可以使用 arp -a 查看。缓存表中的表项有过期时间(一般为20分钟),如果20分钟没有再次使用某个表项,则该表项失效,下次还要发送ARP请求来获得某目的主机的硬件地址。

5.4.3 ARP 数据包格式

在这里插入图片描述

  • 注意到源MAC地址、目的MAC地址在以太网首部和ARP请求中各出现一次,对于链路层为以太网的情况是多余的,但如果链路层是其他类型的网络则可能是有必要的。
  • 硬件类型指链路层网络类型,1为以太网
  • 协议类型指要转换的地址类型,0x0800为IP地址;
  • 硬件地址长度对于以太网地址为6字节;
  • 协议地址长度对于和IP地址为4字节;
  • op字段为1表示ARP请求,op字段为2表示ARP应答。

在arp过程中,收到的任何arp报文,都是先看OP!OP决定了arp的类型是请求还是应答。如果是请求报文,看目的以太网地址和目的IP地址;如果是应答看发送端以太网地址和IP地址。

5.4.4 ARP问题

arp会将主机的mac地址和IP地址做映射,并且缓存起来。

  1. arp只有在缓存失效的时候才会进行。
  2. 我可以通过我的IP和子网掩码,得到我的网络号,然后拼接IP地址,ping所有主机,得到所有主机的IP和mac
  3. 如果我收到多次同样的arp应答,我会以最新的为准。
    arp欺骗

5.5 DNS(Domain Name System) 协议

DNS是一整套从域名映射到IP的系统。
TCP/IP协议使用IP网络寻址,但是IP地址不方便记忆。于是主机名就产生了,主机名是一个字符串并且使用hosts文件来描述主机名和IP地址的关系。

可以使用如下命令来查看本主机的host
cat /ect/hosts  

但是这种需要频繁变更host文件,于是产生了DNS系统。

  • 一个组织的系统管理机构,维护系统内的每个主机的IP和主机名的对应关系。
  • 如果新计算机接入网络,将这个信息注册到数据库种;
  • 用户输入域名的时候,会自动查询DNS服务器,由DNS服务器检索数据库,得到对应的IP地址。

域名解析过程:
域名详细过程
在这里插入图片描述

5.6 ICMP协议

ICMP是网络层协议。
一个新搭建好的网络,往往需要先进行一个简单的测试,来验证网络是否畅通;但是IP协议并不提供可靠传输。如果丢包了,IP协议并不能通知传输层是否丢包以及丢包的原因。所以ICMP来了!

5.6.1 ICMP功能

  • 确认IP包是否成功达到目标地址。
  • 通知在发送过程中IP包被丢弃的原因。
  • ICMP也是基于IP协议工作的,但是它并不是传输层的功能,因此把它归为网络层协议;
  • ICMP只能搭配IPv4使用。如果是IPv6的情况下,需要使用ICMPv6。

在这里插入图片描述

5.6.2 ICMP报文格式

ICMP报文详解。

5.6.3 ping命令

在这里插入图片描述

  • 此处ping的是域名,不是url!一个域名可以通过DNS解析成IP地址。
  • ping命令不光能验证网络的连通信,同时也会统计响应时间和TTL。
  • ping命令会先发送一个ICMP Echo Request给对端;

在这里插入图片描述


ping命令是什么端口?
ping命令基于ICMP,是在网络层。而端口号,是传输层的内容。在ICMP中根本不关注端口号这样的信息。

5.6.4 traceroute命令

基于ICMP实现,能够打印出可执行程序主机,一直到目标主机之间经理多少路由器。
在这里插入图片描述

5.7 NAT技术

NAT能够将私有IP对外通信时转化为全局IP。也就是一种将私有IP和全局IP相互转化的技术方法。
NAT技术是通过路由器维护一张私有IP和公有IP的转换表来进行地址转换技术的。
那么当局域网内有多个主机访问同一个外网服务器呢?转换表不就是相同的了,如何判定这个数据包发送给哪个主机呢?
这个时候需要NAPT了。使用IP+port来建立这个关系。
在这里插入图片描述


NAT缺陷:由于这个转换表,有诸多限制:

  • 无法从NAT外部向内部服务器建立连接。
  • 转换表的生成和销毁都需要额外开销。
  • 通信过程一旦NAT异常,即使存在热设备,所有的TCP连接也断开。

5.8 NAT和代理服务器

  • 应用上看:NAT目的是解决IP不足的问题;代理服务器是可以用来翻墙的。
  • 底层实现上看:NAT工作在网络层,代理服务器工作在应用层。
  • 适用范围看:NAT一般在局域网的出口部署;代理服务器可以在局域网做,也可以在广域网做,也可以跨网。
  • 部署位置:NAT一般集成在防火墙,路由器等硬件设备上;代理服务器是一个软件程序,需要部署在服务器上。

代理服务器分为正向代理和反向代理。
代理服务器详细介绍。