计算机网络
UDP和TCP的区别
- TCP是面向连接的(即通信前需要提前建立连接),UDP是面向无连接的(无需建立连接)。
- UDP程序结构比较简单。
- TCP是面向字节流的,UDP是基于数据报的。
- TCP可以保证数据正确性和顺序,可提供可靠的服务。但UDP无法保证,其只做到尽最大努力交付。
- UDP具有较好的实时性,其工作效率比TCP高,适用于对高速传输和实时性有较高要求的通信或广播通信。
- TCP是一对一的连接,但UDP支持一对多、一对一、多对一和多对多等交互通信。
- TCP对系统资源要i求较多,UDP对系统资源要求较少。
TCP的概念
- TCP是一种面向连接的,提供可靠交付和全双工通信,基于字节流的端到端通信协议;
- TCP在传输数据之前必须优先建立连接,在数据结束之后需要释放连接;
- TCP提供可靠交付,通过TCP连接传输的数据,无差错、不丢失、不重复且按序到达;
- TCP是面向字节流的,虽然应用进程和TCP的交互是一次一个数据块,但TCP将应用程序交付下来的数据堪称仅仅是一连串的无结构的字节流,其不关心传输字节流的含义。
UDP的概念
- UDP是一种无连接的,尽最大努力交付的,基于报文的端到端的传输层通信协议;
- UDP在发送数据之前不需要建立连接;
- UDP不保证可靠的交付,其主机不需要建立复杂的联系状态;
- UDP是面向报文的,其对应用层交下来的报文,不合并、不拆分,而是保留这些报文的边界,每次发送一个报文。在接收端,UDP一次交付一个完整的报文;
- UDP没有拥塞控制,网络出现的拥塞不会使源主机的发送速率降低;
- UDP支持一对一、一对多、多对一、多对多的交互通信;
- UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短。
TCP的粘包问题怎么解决
粘包问题
- TCP粘包问题主要指的是应用层的数据包,指的是发送方发送的若干数据到达接收方时粘成了一个包,从接收缓冲区来看,后一包数据的头紧跟着前一包数据的尾。
解决方法
- 对于定长的包,保证每次按照固定大小读取即可;
- 对于变长的包,在包头的位置约定一个总包长度的字段,从而得知包的结束位置;
- 对于变长的包,可以在包和包之间使用明确的分隔符;
- 可使用TLV格式的数据传输。
TCP第四次挥手为什么要等待2MSL
当客户端进入TIME_WAIT抓过你太的时候,需要经过时间计数器设置事件2MSL(最长报文段寿命)后,才会进入关闭状态。
- 保证客户端发送最后一个ACK报文段能够打到服务器,因为这个ACK有可能会丢失,因此会导致在LAST_ACK状态的服务器无法收到FIN_ACK的确认保温。服务器会超时重传FIN_ACK,接着等待客户端崇传一次确认,重新启动时间等待计数器。若客户端不等待2MSL而是发送完ACK直接端口,一旦ACK丢失,则服务器无法正常进入关闭连接状态;
- 可以防止已失效的报文段。客户端在发送最后一个ACK后,在经过2MSL,可以使本连接持续时间内所产生的所有报文段都从网络中小时,保证关闭连接后不会有网络中滞留的报文段反馈骚扰服务器。
TCP为什么是可靠连接
- TCP通过校验和、重传机制、序号标识、滑动窗口、确认应答等可实现可靠传输。
- 通过TCP连接传输的数据无差错、不丢失、不重复,且按顺序到达
- TCP报文头里面的序号可以使TCP的数据按序到达
- 报文头里的确认序号可以保证不丢包、累计确认和超时重传机制
- TCP具有流浪控制和拥塞控制机制
具体措施
- 应用数据被分割成TCP认为最适合发送的数据块,而UDP不做任何处理;
- TCP发出一个段后,启动一个定时器,等待目的端口确认收到这个报文段。若无法及时收到一个确认,将重发这个报文段(超时重传);
- 当TCP收到发自TCP连接另一端的数据,其对包进行完整校验,并发送一个确认;
- TCP将保持其首部和尾部的检验和,其目的是检测数据在传输过程中是否出现变化。若检验和有差错,则TCP丢弃此报文同时不确认收到此报文段(校验机制);
- TCP对收到的顺序进行重新排序,将收到的数据按照正确的顺序交给应用程;
- TCP接收端会针对重复的数据进行丢失;
- TCP可提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP接收端只允许另一端发送接收端缓冲区所能接纳的数据,防止较快的主机导致较慢主机的缓冲区溢出。
TCP和UDP分别对应的协议
TCP对应的协议
- FTP:文件传输协议,使用21端口;
- Telent:一种用于远程登陆的端口,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务;
- SMTP:邮件传输协议,用于发送邮件,服务器开放的是25端口;
- POP3:与SMTP协议对应,用于接收邮件,使用110端口;
- HTTP:从Web服务器传输超文本到本地浏览器的传送协议,使用80端口。
UDP对应的协议:
- DNS:用于域名解析服务,将域名地址转换为IP地址,使用53号端口;
- SNMP:简单网络管理协议,使用161端口,用于管理网络设备;
- TFTP:简单文件传输协议,在69端口上使用UDP服务
TCP的拥塞控制原理
慢开始、拥塞避免、快重传、快恢复
- 发送放维持一个“拥塞窗口”的变量,该变量与接收窗口共同决定了发送者的发哦那个窗口。发送方的发送窗口上限值应当为接收方窗口rwnd喝拥塞窗口cwnd两个变量中较小的一个;
- **慢开始:**当主机开始发送数据时,为避免一下子将大量字节涌入网络中,造成或增加拥塞,发送方选择发送1字节的试探报文;
- 当收到第一个字节的数据的确认后,就发送2个字节的报文,从此一次递增2的指数级;
- 最后会到达一个提前预设的“慢开始门限sstresh”,此时遵循以下算法:
若 cwnd < sstresh,停止使用慢开始算法;
若 cwnd > sstresh,停止使用慢开始算法,改用拥塞避免算法;
若 cwnd = sstresh,既可以使用慢开始算法,又可以使用拥塞避免算法; - **拥塞避免算法:**每经过一个往返时间RRT就将发送方的拥塞窗口+1,让拥塞窗口缓慢增大,按照线性规律增长;
- 当出现网络拥塞,将慢开始门限ssthresh设置为出现拥塞时的发送窗口的一半(但不能小于2),然后将cwnd设为1,开始执行慢开始算法;
- 快重传机制:
1、接收方建立机制:如果一个包丢失,则对后续的包继续发送针对该包的重传请求;
2、一旦发送方接收三个一样的确认,就知道该报出现了错误,立即重传该包;
3、此时执行快恢复算法:
a、慢开始的门限变为出现拥塞时的一半;
b、拥塞窗口cwnd设为上面变化后的慢开始的门限值;
c、执行拥塞避免算法(高起点,线性增长);
浏览器输入URL后的流程
1、 在浏览器地址输入url;
2、 浏览器先查看浏览器缓存-系统缓存-路由器缓存,若缓存中存在,则直接在屏幕显示页面内容。若没有,则跳转到步骤三;
- 浏览器缓存:浏览器会记录DNS一段时间,因此只是第一个地方解析DNS请求;
- 操作系统缓存:若浏览器缓存中不包含记录,则调用操作系统,获取操作系统的记录(操作系统会保存最近的DNS查询缓存);
- 路由器缓存;
- ISP搜索;
3、在发送http请求之前,进行域名解析(DNS解析),获取相应的IP地址;
4、浏览器向服务器发送TCP连接,与浏览器建立TCP三次握手;
- 第一次握手(发送连接请求):客户端将标志位SYN置为1,随机产生一个值seg=J的数据包到服务器,客户端进入SYN_SENT状态,等待服务器端确认;
- 第二次握手(回应连接请求):服务端收到数据包后由标志位SYN=1知道客户端建立请求连接,服务端将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K并将该数据包发送给客户端以确认连接请求,服务器端进入SYN_RCVD状态;
- 第三次握手(收到回应,最后确认):客户端收到确认后,检查ack是否为J+1,ACK是否为1。若正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务端,服务端检查ack是否为K+1,ACK是否为1。若正确则建立连接,完成三次握手。只有第三次握手可以包含数据。
5、握手成功后,浏览器向服务器发送HTTP请求,请求数据包;
6、服务器处理收到的请求,将数据返回至浏览器;
7、浏览器收到HTTP响应,获取页面内容,浏览器进行渲染,解析html源码;
8、生成Dom树,解析css样式、js交互;
9、客户端与服务器交互;
10、ajax查询;
11、断开TCP连接;
- 第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态;
- 第二次挥手:Server收到FIN后,发送ACK给Client,确认序号为收到序号+1,Server进入CLOSE_WAIT状态;
- 客户端收到服务端的ACK后,进入FIN_WAIT_2状态;
- 第三次挥手:Server处理完数据后,发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态;
- 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
- 客户端经过2MSL事件后,自动进入ClOSED状态,客户端关闭连接。
DNS解析过程
1、浏览器先检查自身缓存中是否存在被解析过的域名对应的ip地址,若果有,解析结束;
2、如果浏览器缓存中没有,浏览器检查操作系统缓存中有没有对应的已解析的结果;
3、若还未命中域名,则请求本地域名服务器(LDNS)来解析域名;
4、若LDNS未命中,则跳到Root Server域名服务器请求解析;
5、根域名服务器返回给LDNS一个所查询域的主域名服务器(gTLD Server)地址;
6、此时LDNS发送请求给上一步返回的gTLD;
7、请求接受的gTLD查找并返回这个域名对应的Name Server地址,即网站注册的域名服务器;
8、Name Server根据映射关系表找到目标ip,返回给LDNS;
9、LDNS焕春这个域名和对应的ip;
10、LDNS将解析的结果返回给用户,用户根据TTL值缓存到本地系统缓存中,域名解析至此结束。
TCP和UDP的区别
- 连接
- TCP是面向连接的传输层协议,传输前要先建立连接;
- UDP是不需要连接,即刻传输数据。
- 服务对象
- TCP是一对一的两点服务,即一条连接只有一个端点;
- UDP支持一对一、一对多、多对对的交互通信。
- 可靠性
- TCP是可靠交付数据的,数据可以无差错、不丢失、不重复、按需到达;
- UDP是金最大努力交付,不保证可靠交付数据。
- 拥塞控制、流量控制
- TCP有拥塞控制和流量控制机制,保证数据传输的安全性;
- UDP则没有,即使网络拥堵,也不会影响UDP的发送速率。
- 首部开销
- TCP首部长度较长,会有一定开销,首部在没有使用[选项]字段时是20字节,若使用则会边长;
- UDP首部只有8字节,而且固定不变开销较小。
- 传输方式
- TCP是流式传输,没有边界,但是保证顺序和可靠;
- UDP是一个包一个包的发送,是有边界的,但可能会丢包和乱序;
- 分片不同
- TCP的数据大小如果大于MSS大小,则会在传输层进行分片,目标主机收到后,也同样在传输层组装TCP数据包,如果丢失了一个分片,则需要重新传输这个分片;
- UDP的数据大小如果大于MTU大小,则会在IP层进行分片,目标主机收到后,则在IP组装完数据,接着在传输给传输层,若途中丢失了一个分片,则需要传输所有的数据包,通常UDP报文应该小于MTU。
为什么TCP三次握手才能保证双方具有接受和发送的能力
- 三次握手才可以阻止重复历史连接的初始化
- 三次握手才可以同步双方的初始化序列号
- 三次握手才可以避免资源浪费
- 避免历史连接
- 客户端连续发送多次SYN建立连接的报文,在网络拥堵情况下:
- 一个“旧SYN报文”比“最新的SYN报文”早到达了服务端;
- 此时服务器返回一个
SYN + ACK
报文给客户端; - 客户端接收后,可以判断这是一个历史连接,此时客户端发送
RST
报文给服务端,表示中止这次连接;
- 如果是两次握手链接,则不能判断当前连接是否是历史连接,三次握手则可以在客户都安准备发送第三次报文时,客户端有足够的上下文来判断是否是历史连接:
- 如果是历史连接,则第三次报文发送
RST
报文,以此中止历史连接; - 如果不是历史连接,则第三次发送的报文是
ACK
报文,通信双方就会成功建立连接;
- 如果是历史连接,则第三次报文发送
- 同步双方初始化序列号
- TCP协议的通信双方,都必须维持一个序列号,序列号是可靠传输的关键因素,其作用为:
- 接收方可以去除重复的数据;
- 接收方可以根据数据报的序列号按序接受;
- 可以标识发哦能够输出取得数据包中,那些事已经被对方收到的;
- 当客户端发送携带“初始序列号”的
SYN
报文时,需要服务端返回一个ACK
应答报文,表示客户端的SYN
报文已经被成功接收,当服务端发送“初始序列号”给客户端的时,也要得到客户端的回应,从而确保双方的初始序列号能被可靠的同步。
- 避免资源浪费
- 如果只有两次握手,若客户端的
SYN
报文在网络中阻塞,客户段没有接收到ACK
报文,就会重新发送,若没有第三次握手,则客户端无法确认是否收到了自己发送的链接的ACK
确认信号,所以没收到一个SYN
就只能先主动建立一个连接。若客户端的SYN
被阻塞,重复发送多次SYN
报文,那么服务器在收到请求后会建立多个冗余的无效链接,造成了资源的浪费。 - 三次握手就已经理论上建立了可靠的链接,不需要使用更多的通信次数。
Socket编程
- 服务端和客户端初始化socket,得到文件描述符;
- 服务端调用bind,将绑定在IP地址和端口;
- 服务端调用listen,进行监听;
- 服务端带调用accept,等待客户端连接;
- 客户端调用connect,向服务端的地址和端口发送连接请求;
- 服务端accept返回用于传输的socket文件描述符;
- 客户端调用write写入数据,服务端调用read读取数据;
- 客户端断开连接时,会调用close,则服务端read读取数据则读取到EOF,带处理完数据后,服务端调用close,表示连接关闭。
HTTP特性
- 优点:
- 简单:其报文格式是header+body,头部信息是key-value,易于理解;
- 灵活且易于拓展:HTTP工作应用层,下层可以随意变换,且其请求方法、URI/URL、状态码、头部字段等没有被固定死,允许开发人员自定义和扩充;
- 应用广泛和跨平台。
- 缺点:
- 无状态:虽然服务器不会记忆HTTP的状态,因此不需要额外的资源来记录状态信息,可以减轻服务器的负担,但是在完成关联性操作时会非常麻烦。其主要解决方法为Cookie技术:通过请求和响应报文中加入Cookie信息来控制客户端状态。
- 明文传输虽然易于阅读虽然方便阅读,但是信息容易被窃取。
- 不安全:这是HTTP最严重的缺点。明文通信会导致内容被窃听、不验证身份会导致伪装、不验证完整性内容容易被修改。可通过引入SSL/TLS层,使用HTTPS保证安全。
- HTTP/1.1关键性能
- 长连接:HTTP/1.1提出长连接通信方式,保证了持久连接,减少额外开销和服务器负载。
- 管道网络传输:在同一个TCP连接中,客户端可发起多个请求,只要第一个请求发出去了,不必等其回来即可发送第二个请求。
- 队头阻塞:由于HTTP是“请求-应答”模式,当顺序发送的请求序列因为某种原因被阻塞时,后面排队的所有请求也会被一同阻塞。
HTTP与HTTPS
HTTP与HTTPS的区别
- HTTP是超文本传输协议,信息是明文传输,存在安全问题。HTTPS则是在TCP和HTTP网络层之间加入SSL/TLS安全协议,使得报文加密;
- HTTP通过TCP三次握手即可进行报文传输,HTTPS则是要在TCP三次握手之后进行SSL/TLS握手,才能进行加密报文传输;
- HTTP端口号是80,HTTPS端口号是443;
- HTTPS协议需要向CA(证书权威机构)申请数字证书,保证服务器身份可信。
HTTPS如何保证通信安全
- 信息加密-混合加密:采用对称加密和非对称加密的混合加密方式;
- 校验机制-摘要算法:实现完整性,解决篡改风险;
- 身份证书-数字证书:使用公钥加密信息,使用私钥解密信息。
SSL/TLS协议基本流程
- 客户端向服务器索要验证服务器的公钥;
- 双方协商产生“会话私钥”;
- 双方采用“会话私钥”进行加密通信。
SSL/TLS协议建立详细流程
- ClientHello:客户端向服务器发哦是那个加密通信请求。发送内容有:SSL/TLS版本号、客户端产生随机数、客户端支持的密码套件列表;
- SeverHello:服务器收到客户端请求后,发出响应。响应内容有:SSL/TLS版本号确认、服务器产生随机数、确认密码套件列表、服务器数字证书;
- 客户端回应:客户端收到服务器回应后,确认数字证书真实性,随后使用服务器公钥发送加密报文。发送内容有:一个随机数、加密通信算法改变通知、客户端握手结束通知;
- 服务器回应:服务器收到客户端随机数后,进行解密获得本次通信会话私钥,随后发送响应。响应内容有:加密通信算法改变通知、服务器握手结束通知。
HTTP/1.1、HTTP/2、HTTP/3的演变
HTTP/1.1相对于HTTP/1.0:
- 增加长连接;
- 支持管道网络传输。
- 仍有瓶颈:
- 请求/响应头部未经压缩即发送;
- 发送冗长的首部,每次发送的首部信息相同;
- 服务器按顺序相应,容易造成队头阻塞;
- 没有请求优先级控制;
- 请求只能从客户端开始,服务器被动响应。
HTTP/2(基于HTTPS)相对于HTTP/1.1
- 头部压缩:若发送多个请求,且头部一样或相似,则会消除重复(HPACK算法:客户端和服务器同时维护一张头部信心表,所有字段在表中生成索引,因此只需发送索引号即可)。
- 二进制格式:头部信息和数据体都是用二进制,且统称为帧。
- 数据流:通过数据包标记确定属于哪个回应,且客户端可以指定数据流的优先级。
- 多路复用:可以在一个连接中发送多个请求或响应,不用按照顺序一一对应,解决队头阻塞问题。
- 服务器推送:服务器可以主动向客户端发送消息。
- HTTP/2仍有缺陷:
- 多个HTTP请求复用一个TCP连接,若发送丢包现象,TCP会触发重传机制,导致所有HTTP请求必须等待被丢失的包重传。即一旦发生丢包,会阻塞所有的HTTP请求。
HTTP/3主要改动
- HTTP/3将TCP协议改成了UDP协议。
- 基于UDP的QUIC协议保证传输的可靠性。
- 头部算法升级成QPack
- HTTPS需要建立连接需要六次交互,QUIC直接将TCP和TLS/1.3握手合并成了3次。
HTTP/1.1如何优化
- 尽量避免发送HTTP请求。解决方法:缓存。
- 在需要发送HTTP请求时,考虑如何减少请求次数。解决方法:减少重定向请求次数、合并请求、延迟发送请求;
- 减少服务器相应的数据大小。解决方法;无损压缩、有损压缩。
HTTPS如何优化
- 分析性能损耗:TLS协议握手过程、握手后的对称加密报文传输;
- 硬件优化:选择支持AES-NI特性的CPU(HTTPS是计算密集型);
- 软件优化:升级Linux内核、升级OpenSSL;
- 会话服用
- 协议优化:密钥交换算法优化-使用ECDHE、TLS升级;
- 证书优化:证书传输优化-使用ECDSA证书、证书验证优化;
TCP重传机制
- 超时重传:发送数据时,设定一个定时器,当超过指定时间后,若没有收到对方的ACK确认应答报文,则重新发送该数据。再次超时时,TCP的策略是超时间隔加倍。
- 快速重传:当受到三个相同的ACK报文时,会在定时器过期之前重传丢失的报文段。
- SACK(选择性确认):在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄,它可以将缓存的地图发送给发送⽅,这样发送⽅就可以知道哪些数据收到了,哪些数据没收到,知道了这些信息,就可以只重传丢失的数据。
- D-SACK:使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。
TCP半连接队列和全连接队列
在TCP握手的时候,Linux内核会维护两个队列:
- 半连接队列:SYN队列;
- 全连接队列:accepet队列。
服务端在收到客户端发起的SYN请求后,内核会把连接存储到半连接队列,并向客户端响应SYN+ACK,接着客户端返回ACK,服务端收到第三次握手的ACK后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到accept队列,等待进程调用accept函数时把连接取出来。
TCP第一次握手在收到SYN包时会被丢弃的三种条件:
- 如果半连接队列满了,并且没有开启tcp_syncookies,则会被丢弃;
- 如果全连接队列满了,且没有重传SYN+ACK包的连接请求多余1个,则会被丢弃;
- 如果没有开启tcp_syncookies且max_syn_backlog减去当前半连接队列长度小于max_syn_backlog>>2,则会被丢弃。
防御SYN攻击的方法:
- 增大半连接队列;
- 开启tcp_syncookies功能;
- 减少SYN+ACK重传次数。
提升TCP的策略
TCP三次握手的性能提升
使用netstat
命令查看是哪个握手阶段出现问题,对症下药。
- 调整SYN报文重传次数(客户端优化)
- 调整SYN半连接队列长度(服务端优化):可根据
netstat -s
命令得到的统计结果确认 - 调整SYN+ACK报文重传次数
- 调整accpet队列长度:可通过
ss -ltn
命令查看 - 绕过三次握手(TCP Fast Open功能可减少TCP连接建立的时延)
TCP四次挥手的性能提升
- 调整FIN报文重传次数(主动方的优化)
- 调整FIN_WAIT2状态的时间
- 调整孤儿连接的上限个数
- 调整time_wait状态的上限个数
- 调整time_wait状态的连接
TCP数据传输的性能提升
- 扩大窗口大小
- 调整发送缓冲区范围
- 调整接收缓冲区范围
- 接收缓冲区动态调节
- 调整内存范围
IPv6相对于IPv4的首部改进
- 取消了首部校验和字段:因为在数据链路层和传输层都会进行校验;
- 取消了分片/重新组装相关字段:IPv6不允许在中间路由器进行分片与重铸,只能在源于目标主机进行;
- 取消选项字段。
IP协议相关技术
DNS域名解析
-
客户端⾸先会发出⼀个 DNS 请求,问 www.server.com 的 IP 是啥,并发给本地 DNS 服务器(也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址)。
-
本地域名服务器收到客户端的请求后,如果缓存⾥的表格能找到 www.server.com,则它直接返回 IP 地址。如果没有,本地 DNS 会去问它的根域名服务器: “⽼⼤, 能告诉我 www.server.com 的 IP 地址吗? ” 根域名服务器是最⾼层次的,它不直接⽤于域名解析,但能指明⼀条道路。
-
根 DNS 收到来⾃本地 DNS 的请求后,发现后置是 .com,说: “www.server.com 这个域名归 .com 区域管理”,我给你 .com 顶级域名服务器地址给你,你去问问它吧。 ”
-
本地 DNS 收到顶级域名服务器的地址后,发起请求问“⽼⼆, 你能告诉我 www.server.com 的 IP 地址吗? ”
顶级域名服务器说: “我给你负责 www.server.com 区域的权威 DNS 服务器的地址,你去问它应该能问到”。 -
本地 DNS 于是转向问权威 DNS 服务器: “⽼三, www.server.com对应的IP是啥呀? ” server.com 的权威 DNS服务器,它是域名解结果的原出处。为啥叫权威呢?就是我的域名我做主。
-
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
-
本地 DNS 再将 IP 地址返回客户端,客户端和⽬标建⽴连接。
ARP 与 RARP 协议
ARP协议
- 主机通过广播发送ARP请求,这个请求包中包含想知道的MAC地址和主机IP地址;
- 当同个链路中所有设备收到ARP请求时,拆解内容,若请求地址于自己的IP地址一致,则将自己的MAC地址塞入ARP响应包返回给主机。
RARP协议(需要RARP服务器)
- 该设备会发送⼀条「我的 MAC 地址是XXXX,请告诉我,我的IP地址应该是什么」的请求信息。
- RARP 服务器接到这个消息后返回「MAC地址为 XXXX 的设备, IP地址为 XXXX」的信息给这个设备。
- 最后,设备就根据从 RARP 服务器所收到的应答信息设置⾃⼰的 IP 地址。
DHCP 动态获取 IP 地址
- 客户端⾸先发起 DHCP 发现报⽂(DHCP DISCOVER) 的 IP 数据报,由于客户端没有 IP 地址,也不知道DHCP 服务器的地址,所以使⽤的是 UDP ⼴播通信,其使⽤的⼴播⽬的地址是 255.255.255.255(端⼝ 67)并且使⽤ 0.0.0.0(端⼝ 68) 作为源 IP 地址。 DHCP 客户端将该 IP 数据报传递给链路层,链路层然后将帧⼴播到所有的⽹络中设备。
- DHCP 服务器收到 DHCP 发现报⽂时,⽤ DHCP 提供报⽂(DHCP OFFER) 向客户端做出响应。该报⽂仍然使⽤ IP ⼴播地址 255.255.255.255,该报⽂信息携带服务器提供可租约的 IP 地址、⼦⽹掩码、默认⽹关、DNS 服务器以及 IP 地址租⽤期。
- 客户端收到⼀个或多个服务器的 DHCP 提供报⽂后,从中选择⼀个服务器,并向选中的服务器发送 DHCP 请求报⽂(DHCP REQUEST进⾏响应,回显配置的参数。
- 最后,服务端⽤ DHCP ACK 报⽂对 DHCP 请求报⽂进⾏响应,应答所要求的参数。
NAT 网络地址转换
ICMP 互联网控制报文协议
- 查询报文类型:用于诊断的查询消息
- 0:回送应答
- 8:回送请求
- 差错报文类型:通知出错原因的错误消息
- 目标不可达
- 原点抑制
- 重定向或改变路由
- 超时
IGMP 因特网组管理协
ICMP协议(互联网控制报文协议)
主要功能:
- 确认IP包是否成功送达目标地址;
- 报告发送过程中IP包被废弃的原因
- 改善网络设置
Ping的发送与接收过程
- Ping命令执行时,源主机会构建一个ICMP回送请求消息包;
- ICMP协议将数据包联通地址交给IP层;
- 主机B收到数据帧后,检查MAC地址,若符合则接收,否则就丢弃;
- 主机B提取IP数据包交给IP层次;
- 主机B构建ICMP会送响应消息;
- 在规定时间内,源主机若没收到ICMP应答包,则说明主机不可达。
traceroute作用
- 故意设置特殊TTL,追钟去往目的地时沿途经过的路由器;
- 故意设置不分片,确定路径MTU;