后端开发必会的计算机网络原理 - TCP/IP一级目录二级目录三级目录后端开发必会的计算机网络原理 - TCP/IP1.UDP协议1.1 UDP协议端格式1.2 UDP的特点2. TCP协议2.1 TCP协议段格式2.2 TCP的核心机制2.2.1 核心机制一确认应答2.2.2 核心机制二超时重传2.2.3 核心机制三连接管理2.2.3.1 三次握手2.2.3.2 四次挥手2.2.4 核心机制四滑动窗口2.2.5 核心机制五流量控制2.2.6 核心机制六拥塞控制2.2.7 核心机制七延时应答2.2.8 核心机制八捎带应答2.2.9 核心机制九面向字节流2.2.10 核心机制十异常情况的处理3. IP协议3.1 IP的协议头格式3.2 解决IP地址不够用的方法3.2.1 动态分配IP3.2.2 NAT机制3.2.3 IPv63.3 地址管理3.3.1 网段划分3.3.2 特殊的IP地址3.4 路由选择4. 数据链路层4.1 认识以太网4.2 ARP协议5.应用层协议补充--DNS5.1 DNS背景5.2 DNS解决海量请求的方法5.3 DNS与Cookie的区别一级目录二级目录三级目录后端开发必会的计算机网络原理 - TCP/IP1.UDP协议特点无连接不可靠面向数据报全双工通信1.1 UDP协议端格式端口2字节16bit一个端口号的取值范围0-65535实际上一般把1024以下的端口号保留写代码都是用的1024-65535这个范围的。长度属性2字节即16bit因此整个UDP数据报的最大长度为64kb校验和验证数据是否发生了修改校验和的设计不是为了防止黑客篡改与安全性无关而是防止传输过程中出现的比特翻转问题eg,光点信号电信号电磁波这些信号可能受到外界干扰可能会使高低电平翻转。。。发送端数据 1101011011 左移 4 位 → 模 2 除 10011 → 得到余数 1110 → 生成传输帧 1101011011 1110。接收端收到 11010110111110 → 用除数 10011 做模 2 除法 → 最终余数为 0 → 校验通过接收数据。核心逻辑“不管是发送端还是接收端只要用同一个除数做模 2 除法结果余数为 0就证明数据没被篡改且传输正确。”1.2 UDP的特点UDP传输的过程类似于寄信.• 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;• 不可靠:没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;• 面向数据报: 以整个UDP数据报为单位接收/发送数据报不能够灵活的控制读写数据的次数和数量;应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并2. TCP协议TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;2.1 TCP协议段格式源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;序号是为了发送端标识数据确保数据不乱序、不重复。确认号ACK是为了接收端反馈状态告诉发送端 “我已经正确拿到了哪些数据”。6位标志位:◦ URG: 紧急指针是否有效TCP正常来说按照需要发送/接收紧急指针相当于插队跳过前面的数据直接从某个指定的需要开始read◦ ACK: 确认号是否有效◦ PSH: 发送方给接收方发送了数据中带有这个标志位提示接收端应用程序立刻从TCP缓冲区把数据读走◦ RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段◦ SYN:请求建立连接; 我们把携带SYN标识的称为同步报文段◦ FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段16位窗口大小流量控制防止对方挂掉和拥塞控制防止网络堵死16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.16位紧急指针: 标识哪部分数据是紧急数据;40字节头部选项头部选项是在这 20 字节基础上的可选扩展部分其最大长度为 40 字节因此 TCP 头部总长度最大为 204060 字节、URG VS PSH对比维度URG紧急标志PSH推送标志触发对象作用于 TCP 协议层让接收端 TCP 优先处理紧急数据作用于应用层提示接收端应用程序立刻读取缓冲区数据数据处理方式紧急数据会插队跳过普通数据直接交付给应用程序普通数据仍按顺序处理不改变数据顺序只是催促应用层尽快读取缓冲区中的所有数据不会跳过任何字节优先级真正的高优先级紧急数据会被优先处理不受正常流量控制顺序影响只是“催促”没有优先级提升数据仍按字节流顺序传输只是让应用层不要延迟读取使用场景用于紧急中断类场景如终端的 CtrlC 中断、远程控制的紧急指令用于实时交互场景如 HTTP 请求/响应、聊天消息避免数据在缓冲区堆积延迟交付2.2 TCP的核心机制可靠性这里所说的可靠性不是说A给B发消息B能够100%收到而是A想各种办法尽量让B收到2.2.1 核心机制一确认应答保证可靠性的一个关键前提是发送方知道自己已经发送的数据是否被接收方收到。接收方在收到发送方的消息之后需要返回一个应答报文acknowledgeack发送方知道应答报文就可以确认对方是否收到了但是如果只有ack应答报文则会出现严重的问题TCP将每个字节的数据都进行了编号. 即为序列号. 因此我们写TCP协议的代码时完全不用考虑数据顺序的问题。每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据;下一次你从哪里开始发.注意上图中的Seq1001和Ack1001并不冲突数据报文中的 Seq (序号) 1001这是主机 A发出去的数据报文。意思是主机 B这是我发给你的数据流我的这段数据是从编号 1001 开始的。告诉接收方我这一包数据的起点在哪里。确认报文中的 ACK (确认号) 1001这是主机 B发回来的ACK 报文。意思是主机 A我已收妥你之前发的所有数据期待你下次从编号 1001 开始发给我。可以告诉发送方我这个接收窗口的下一个空位在哪里。2.2.2 核心机制二超时重传当主机A给主机B发送数据但是没有收到主机B的响应报文这里有两种情况数据在传输给B的过程当中丢失主机B的应答报文丢失我们可以引入超时时间来判断是否发生了以上两种丢包的情况。TCP中判定超时的时间阈值不是固定的数值是动态改变的这里的动态改变时间我来简单说一下假设目前A向B发送数据设置的丢包超时间为T当A给B传输发生超时之后就会延长这个时间阈值。当然这个超时重传的时间阈值不会一直延长当超时次数达到一定程度/B等待时间达到一定程度就认为网络出现严重故障就会放弃这一次传输。这里需要注意主机A给主机B发送数据但是B的ack丢失引发A的超时重传此时主机B的应用层会读到2份同样的数据如果这是扣款数据的话就会有很大的问题为了解决这种数据重复的问题当一个新的报文到达时TCP 首先提取出这个报文的序号然后TCP 立刻去接收缓冲区里查找看这个序号对应的字节是否已经存在于缓冲区里了如果存在了则直接丢弃新到达的报文若不存在则放入接收缓冲区等待应用层的读取。高频面试题TCP中哪些机制保证了TCP能够进行可靠传输确认应答ack超时重传2.2.3 核心机制三连接管理2.2.3.1 三次握手客户端与服务端使用TCP协议通信的建立连接的过程我们可以使用三次握手来描述正常的情况是服务端发送一次连接请求对于客户端连接请求的应答报文客户端发送一次连接请求对于服务端请求的应答报文。其中服务端的应答报文和请求连接报文能合二为一注意三次握手中最后一次客户端向服务器的应答报文的作用回应服务器客户端已经收到服务器的请求若没有这一次服务器仍然不知道客户端是否答应三次握手的作用2.2.3.2 四次挥手有人可能会有疑问三次握手中服务器的SYN和ACK可以合并所以在四次挥手中服务器的ACK和FIN可不可以合并答案是不能ack/syn是操作系统内核控制返回的当内核收到FIN第一时间返回ack/syn和你程序代码无关第二个FIN则是代码中调用socket.close()才会触发的进程结束也会触发因此第二个FIN的时机和ack的时机很可能不是同一时机三次握手与四次挥手的区别TCP连接的状态解析TIME_WAIT进入TIME_WAIT的时机当被动关闭方客户端最后一次发送完 ACK 确认报文后立刻进入 TIME_WAIT 状态被动关闭方比如客户端进入 TIME_WAIT它要等待的时间分成两部分第一个方向它发出的 FIN 在网络里可能延迟、丢失、重传 → 等待 1MSL 确保所有旧数据彻底消失。第二个方向它发出的 ACK 可能丢失 → 服务器会重发 FIN → 再等 1MSL 确保这方向也干净。合起来就是1MSL等待 FIN 消失 1MSL等待 ACK 重传 FIN 2MSL想一想, 为什么是TIME_WAIT的时间是2MSL?•MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);CLOSE_WAITCLOSE_WAIT的存在时间蓝色标记部分正处于被动关闭方连接被关闭方且正处于收到 FIN 并回了 ACK 之后、但还没有主动 close 之前的这段时间起点收到 FIN 并回复 ACK 之后。终点主动调用 close () 发送 FIN 之前。一般而言对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题.2.2.4 核心机制四滑动窗口刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段. 这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.滑动窗口策略可以利用一份等待时间来发送多份数据获取多个ack应答报文窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).• 发送前四个段的时候, 不需要等待任何ACK, 直接发送;• 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;• 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;• 窗口越大, 批量发送的数据越多效率就越高但是窗口也不能无限大太大也会影响到可靠性滑动窗口是在可靠传输的基础上提高效率当然使用滑动窗口的过程中也存在一定丢包的概率这里有两种情况情况一数据包到达目的主机但是应答报文ack丢失此时不用做任何处理因为之后到达源主机的ack应答报文里面的内容会涵盖前一个ack的含义情况二数据包在发送给目的主机的时候丢失了这种情况的解决方法–快重传• 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端我想要的是1001;• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;• 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;这种机制被称为 “高速重发控制”(也叫快重传).注意超时重传vs快重传相同点TCP 发送方会为每个发出的报文段维护一个 重传定时器同时接收方会对收到的报文段回复 确认报文ACK。重传机制的本质是发送方没收到预期的 ACK 时重新发送丢失的报文段区别维度超时重传快重传触发条件重传定时器超时连续收到 3 个重复 ACK重传延迟高几百毫秒几秒低几乎即时核心逻辑被动等待主动检测对网络的适应性差超时时间难适配好基于实际 ACK 反馈依赖条件仅依赖发送方定时器依赖接收方重复 ACK2.2.5 核心机制五流量控制接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.流量控制形象的来说就是给发送方踩刹车让它发的慢点流量控制可以让接收方根据自身处理数据的速度反馈给发送方限制发送方的发送速度。2.2.6 核心机制六拥塞控制虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵.在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;我们先要清楚流量控制与拥塞控制的区别此处引入一个概念程为拥塞窗口• 发送开始的时候, 定义拥塞窗口大小为1;•每次收到一个ACK应答, 拥塞窗口加1;• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.• 此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长此时拥塞窗口值每过一个传输轮次就增加1.• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;如果该过程中少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;2.2.7 核心机制七延时应答默认情况下接收方都是在收到数据报第一瞬间就返回ack但是可以通过延时返回ack的方式来提高效率假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;一定要记得,窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;是不是收到每一个TCP报文段之后都可以延时应答吗当然不是• 数量限制: 每隔N个包就应答一次;• 时间限制: 超过最大延迟时间就应答一次;具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;2.2.8 核心机制八捎带应答在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端引入捎带应答之后当客户端发来请求时服务端可以不立即返回ack可以发送响应报文段的同时把ack也代入到响应数据中一起返回把这两个报文段合二为一就能起到提高效率的作用2.2.9 核心机制九面向字节流由于TCP报文段是以字节为单位传输这样很容易混淆报文段之间的边界从而接收方无法区分从哪里到哪里是一个完整的应用层数据包。这种问题叫做粘包问题当接收方执行read操作时会不知道到底一次读取几个字节可以读出a,aa,aaa…首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.• 站在应用层的角度, 看到的只是一串连续的字节数据.• 那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可如’/n’);注意「以字节为单位传输」不是说一次只发 1 字节而是说TCP 对数据的编号、确认、流量控制、拥塞控制都是以「单个字节」为最小粒度把数据当作无边界的字节流来处理而不是以「报文段」或「应用层消息」为单位2.2.10 核心机制十异常情况的处理某个进程崩溃了这种情况和主动退出没有本质区别进程释放–先回收文件描述符表的每个资源然后调用socket的close触发四次挥手操作虽然进程没了但是TCP的连接信息还在此时四次挥手可以正常进行主机关机了正常的关机流程本质上会先杀死所有用户进程关机也需要一定的时间在一定时间内a. 如果挥手完了就没有问题。b. 如果没有完成挥手操作在以下情况中主机B收不到对于自己发送的FIN报文段的回复最终B主动释放和A的连接主机掉电了/网线断开如果接收方掉电同网线断开发送方视角)发送方突然掉电同网线断开接收方视角3. IP协议基本概念• 主机: 配有IP地址, 但是不进行路由控制的设备;• 路由器: 即配有IP地址, 又能进行路由控制;• 节点: 主机和路由器的统称;3.1 IP的协议头格式四位版本号分为IPv4和IPv6四位首部长度:IP头部总长度首部长度字段值×4IP 头部的最大长度是 60 字节。其中固定部分占了 20 字节。剩下的60−2040字节就是用来存 “可选字段Options” 的空间。16位总长度字节数2的16次方64KB16位标识IP 数据报如果在数据链路层传输时需要分片那么同一个原始 IP 包分成的所有分片都会使用相同的标识ID。当这些分片到达目标主机、从数据链路层上交给网络层后主机会根据 ID、源 IP、目的 IP、协议号把具有相同标识的分片收集起来按偏移量重新组装成一个完整的 IP 数据报再交给上层协议。8位生存时间TTL可以使用winr操作打开命令提示符ping baidu.com 可以看到TTL值为50初始值为64可见经过了14次路由转发8位协议由于IP 自己不知道自己的数据载荷部分装的是TCP/UDP所以它头部里放了一个 8 位数字用来告诉接收方的操作系统我这个包里装的是什么协议你交给对应的上层模块IP 头里的 8 位协议号就是一个 “分发编号”告诉系统这个包里装的是 TCP、UDP 还是 ICMP。16位首部校验和源IP地址/目的IP地址3位标志字段:第一位保留(保留的意思是现在不用, 但是还没想好说不定以后要用到).第二位置为1表示禁止分片, 这时候如果报文长度超过MTU, IP模块就会丢弃报文.第三位表示更多分片, 如果分片了的话, 最后一个分片置为1, 其他是0. 类似于一个结束标记.13位分片偏移(framegament offset): 是分片相对于原始IP报文开始处的偏移需要在原始数据的基础上*8. 其实就是在表示当前分片在原报文中处在哪个位置. 因此, 除了最后一个报文之外, 其他报文的长度必须是8的整数倍(否则报文就不连续了)3.2 解决IP地址不够用的方法由于32位的IP地址的数量有限限制已经几乎被耗尽因此需要能够解决IP地址资源耗尽的方法3.2.1 动态分配IP当某台设备需要上网的时候为其分配IP地址不需要上网时则把该IP地址分配给其他需要上网的设备3.2.2 NAT机制NAT机制即网络地址转换这也是当前网络世界最主要的解决IP地址资源枯竭的解决方案NAT机制就可以用一个外网IP对应到一系列的内网设备这样由于私网IP可以重复在一定程度上缓解了该问题首先需要把所有的IP地址分成两个大类公网IP/私网IP图中介绍了NAT机制主要的几个阶段阶段一内网发送原始请求画面左侧是三台内网主机它们的 IP 地址属于局域网私有地址如 198.1.1.5/6/7各自发起了对外访问请求目的端口均为 9090假设为目标服务端口。主机 198.1.1.5源端口 12345。主机 198.1.1.6源端口 23456。阶段二NAT 转换核心过程数据到达中间的运营商服务器NAT 设备 后发生了关键的转换源 IP 替换将内网源 IP198.1.1.x替换为公网出口 IP100.1.1.1。源端口改写为了区分不同的内网请求NAT 设备修改了源端口号。原本 198.1.1.5:12345 → 转换为 100.1.1.1:12345。原本 198.1.1.6:23456 → 转换为 100.1.1.1:23456。原理公网 IP 地址是有限的而端口号16 位0-65535资源丰富。通过 “公网 IP 端口” 的唯一组合就能精准对应到内网的具体主机和连接。阶段三服务器响应与回传数据到达百度搜索服务器后服务器回复数据。服务器收到的请求源是 100.1.1.1。服务器将回复包的目的 IP设为 100.1.1.1目的端口则分别填回 12345 和 23456。关键点图中的红色箭头指出服务器正是依靠端口号来区分是哪一台内网主机发来的请求从而保证数据能够准确回传给对应的用户。阶段四NAT 设备如何将响应包还原回内网主机当内网主机发起请求、数据包经过 NAT 设备时设备会自动在映射表里添加一条记录公网侧 (公网 IP: 源端口)内网侧 (内网 IP: 源端口)100.1.1.1:12345198.1.1.5:12345100.1.1.1:23456198.1.1.6:23456当百度服务器返回响应包时目的 IP100.1.1.1公网 IP目的端口12345对应之前的请求端口NAT 设备收到后会做两件事查表匹配用 (100.1.1.1, 12345) 去查映射表找到对应的内网条目 198.1.1.5:12345替换目的信息把目的 IP 从 100.1.1.1 改回 198.1.1.5目的端口保持 12345 不变转发给内网将修改后的数据包发给内网主机 198.1.1.5注意公网IP 源端口必须唯一这样才能精准对应到某一台内网主机的某一个连接程序3.2.3 IPv6IPv4是使用4个字节作为IP地址IPv6是使用16个字节作为IP地址这意味着如果把地球上的每一粒沙子分配一个IPv6地址都绰绰有余因此IPv6也是解决IP地址枯竭的终极方案3.3 地址管理3.3.1 网段划分IP地址分为两个部分,网络号和主机号• 网络号: 保证相互连接的两个网段具有不同的标识;• 主机号: 同一网段内, 主机之间具有相同的网络号, 但是必须有不同的主机号3.3.2 特殊的IP地址将IP地址中的主机地址全部设为0, 就成为了网络号, 代表这个局域网;将IP地址中的主机地址全部设为1, 就成为了广播地址, 用于给同一个链路中相互连接的所有主机发送数据包;127.*的IP地址用于本机环回(loop back)测试,通常是127.0.0.13.4 路由选择在复杂的网络结构中, 找出一条通往终点的路线;路由的过程, 是一跳一跳(Hop by Hop) “问路” 的过程.这里所说的路由选择对于路由器来说也是这样的网络环境很复杂对于任何一个路由器都无法存储网络上的所有信息但是每个路由器是可以知道附近网络的情况当数据包到达某个路由器的时候就会匹配这个路由器的路由表路由表中记录了这个路由器周围的设备IP是什么也会记录每个设备要通过哪个口转发过去情况一如果该数据包的目的IP刚好匹配到了路由表中的记录那么直接按照当前的对应的口转发过去就行了情况二如果没有匹配到路由表会有一个特殊表项下一跳指向的设备是上一级路由器所在的位置我们可以按照邮政系统的工作流程来理解这里的路由选择假设你要从天津某小区源主机寄一封信到拉萨某写字楼目的主机第一步小区邮局源主机的网关路由器 你把信交给小区邮局邮局看了一眼地址拉萨不在我的派送范围。 它查自己的 “派送表”路由表发现所有外地信件都要先送到天津市区邮局下一跳。于是把信转发给天津市区邮局。第二步天津市区邮局区域路由器 市区邮局收到信知道拉萨属于西南地区不在自己的派送范围。查路由表发现西南方向的信件都要先送到北京总邮局下一跳。 把信转发给北京总邮局。第三步北京总邮局核心路由器 北京总邮局是全国枢纽它的路由表更全知道拉萨的信件要走西北 - 西南干线先送到成都中转邮局。把信转发给成都中转邮局。第四步成都中转邮局省级路由器 成都邮局知道拉萨属于西藏查路由表后把信转发给拉萨市邮局。第五步拉萨市邮局目的网关路由器 拉萨邮局一看地址就在我的派送范围内直接把信送到最终的写字楼目的主机。4. 数据链路层4.1 认识以太网• “以太网” 不是一种具体的网络, 而是一种技术标准; 既包含了数据链路层的内容, 也包含了一些物理层的内容. 例如: 规定了网络拓扑结构, 访问控制方式, 传输速率等;• 例如以太网中的网线必须使用双绞线; 传输速率有10M, 100M, 1000M等;• 以太网是当前应用最广泛的局域网技术; 和以太网并列的还有令牌环网, 无线LAN等;源地址和目的地址是指网卡的硬件地址(也叫MAC地址), 长度是48位,是在网卡出厂时固化的;• 帧协议类型字段有三种值,分别对应IP、ARP、RARP;• 帧末尾是CRC校验码。4.2 ARP协议IP负责跨网络通信MAC负责同一个局域网内部的通信ARP不是传输业务数据的而是一个辅助协议功能是根据IP地址得到对应的MAC地址网卡/交换机工作在数据链路层只能认识MAC地址网络传输过程中网络这一层转发是要根据IP的数据链路层这一程是根据MAC地址进行转发注意主机 A 和主机 B 通信发的是IP 数据包而在每一段路途上跑的是以太网帧。它们不是二选一的关系而是 外层包裹 vs 核心内容 的关系5.应用层协议补充–DNSDNS是一整套从域名映射到IP的系统5.1 DNS背景TCP/IP中使用IP地址和端口号来确定网络上的一台主机的一个程序. 但是IP地址不方便记忆,于是人们发明了一种叫域名的东西, 是一个字符串方便人们记忆, 并且使用hosts文件来描述主机名和IP地址的关系.DNS服务器就是用来存储这种域名与IP地址的对应关系的。注意DNS是应用层协议DNS底层使用UDP进行解析浏览器会缓存DNS结果浏览器中输入url后, 发生的事情.5.2 DNS解决海量请求的方法随着互联网的发展全世界设备越来越多如果每次发起网络请求都需要先访问DNS服务器的话DNS服务器就要承担海量的并发量那么如何解决上述问题使用缓存你的电脑不会每次请求网站服务的时候都触发DNS请求比如访问baidu.com进行一次DNS之后电脑的缓存就会把IP记录下来了下次再次访问百度就不需要重新访问DNSDNS服务器也有很多个存储原始数据的DNS服务器称为DNS跟服务器各种运营商可以搭建DNS镜像服务器这样可以大大降低用户大规模访问的压力5.3 DNS与Cookie的区别Cookie 是浏览器存用户状态给服务器识别用户为了不用每次都输入登录信息DNS 缓存是本地存域名对应的 IP用来加快解析