计算机网络常考知识点

计算机网络常考知识点

网络协议层次

TCP/IP四层模型：网络接口层、网络层、传输层、应用层；

OSI七层模型：物理层、数据链路层；网络层；传输层；会话层、表示层、应用层；

从浏览器输入网址到界面显示的过程是怎样的

1. DNS解析

2. 与服务器建立HTTP连接：TCP连接、HTTP请求

3. 服务器处理请求并返回报文

4. 浏览器开始进行解析和渲染

5. 断开连接

应用层

代表协议：HTTP, TFTP, FTP, NFS, WAIS, SMTP, Telnet, DNS, SNMP

HTTP

• HTTP(HyperText Transfer Protocol):超文本传输协议
• 格式：https://:/

HTTP与HTTPS的区别

1. HTTP是明文未加密的，HTTPS是加密的；
2. HTTPS 是HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
3. 因此HTTP的相应较快，HTTPS相应较慢。
4. http使用80端口，https使用443端口

HTTP通信的特点

1. 通过请求和响应的模式实现通信
2. HTTP本身是不保存状态的协议

HTTP通信过程

1. HTTP 使用 TCP（而不是 UDP）作为它的支撑运输层协议。其默认工作在 TCP 协议 80 端口；
2. HTTP 客户机发起一个与服务器的 TCP 连接，一旦连接建立，浏览器和服务器进程就可以通过套接字接口访问 TCP。客户机从套接字接口发送 HTTP 请求报文和接收 HTTP 响应报文。

HTTP报文

行+头+体

请求首部

GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0

请求方法

方法	描述
GET	请求指定的页面信息，并返回具体内容，通常只用于读取数据。
POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。
HEAD	类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头。
PUT	替换指定的资源，没有的话就新增。
DELETE	请求服务器删除 URL 标识的资源数据。
CONNECT	将服务器作为代理，让服务器代替用户进行访问。
OPTIONS	向服务器发送该方法，会返回对指定资源所支持的 HTTP 请求方法。
TRACE	回显服务器收到的请求数据，即服务器返回自己收到的数据，主要用于测试和诊断。
PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新。

响应首部

HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"

状态码

HTTP 状态码由三个十进制数字组成，第一个数字定义了状态码的类型，后两个并没有起到分类的作用。HTTP 状态码共有 5 种类型：

分类	分类描述
1XX	指示信息–表示请求正在处理
2XX	成功–表示请求已被成功处理完毕
3XX	重定向–要完成的请求需要进行附加操作
4XX	客户端错误–请求有语法错误或者请求无法实现，服务器无法处理请求
5XX	服务器端错误–服务器处理请求出现错误

常见状态码

状态码	英文名称	中文描述
200	OK	请求成功。请求所希望的响应头或数据体将随此响应返回
204	No Content	请求成功但无内容返回
206	Partial Content	范围请求成功
301	Moved Permanently	永久重定向； 30(2/3/7）
400	Bad Request	语法错误（前端挨打）
403	Forbidden	拒绝访问
404	Not Found	请求失败，请求所希望得到的资源未被在服务器上发现
500	Internal Server	服务器错误（后端挨打）
503	Service Unavailable	服务器宕机了（DevOps or IT 挨打）
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求

HTTPS

• HTTPS是身披SSL外壳的HTTP，HTTP转化到TCP的过程中先经过外壳SSL

• 共享秘钥加密：

  1. 只有一把秘钥，发送端使用秘钥加密，接收端利用相同秘钥解密，效率高；
  2. 只有拥有秘钥的人才能破解被秘钥加密的信息，因此需要保证只有发送端和接收端有秘钥，黑客不能有秘钥
  3. 而陌生通信对象初始不具备秘钥，需要主动端发送秘钥给被动端，而这个发送步骤安全难以保证，期间秘钥可能被截获；

• 公开秘钥加密-两把秘钥：

  1. 接收端具有公开的公钥和保密的私钥，两者为配对的一套，即使用该私钥可以快速解密对应公钥加密的密文（反之也是）；
  2. 公钥共享给发送端，用以加密发送的数据；公钥加密只能用私钥解密，利用公钥反解密相当困难；
  3. 公开密钥处理速度较慢，每一次传送数据都是用公开密钥效率较低
  4. 拥有公钥的客户端向拥有私钥的服务端发送的信息无法被攻击者破解，因为只有拥有私钥的服务器才能解密公钥内容
  5. 拥有私钥的服务端发送的信息可被所有人破解，因为所有人都可获取公钥

• HTTPS采用混合加密：

  1. 利用公开秘钥技术，可以保证公钥端向私钥端发送的信息是安全的，但一对公私钥无法建立双端的安全通信，除非主动端也有一个私钥，请求被动端的公钥，也发送自己的公钥，两者分别用对方的公钥加密通信；但效率较低
  2. 利用单端安全的通信，主动方发送共享秘钥和加密算法，然后被动房保存到本地，之后用着一把秘钥对称加密通信；
  3. 如果客户端已经拥有服务端的公钥，那么服务端发送【明文信息】+{私钥加密的相同信息}，而后客户端进行解密对照内容是否相同，从而得知对方是否具有私钥（对方是否是自己公钥所对应的私钥拥有者），黑客不知道私钥，无法冒充服务端；但前提是客户端拥有的公钥是自己期许的，A认为自己的公钥是B的，那么可被该公钥解密的信息均认为是B的；而A不可能保存世界上所有服务端的公钥，需要现场向B请求公钥，因而出现下面的安全问题；

• 公开秘钥的安全性：

  1. 问题举例：在第一步请求公钥时，中间人截取接收端的真公钥，发给发送端自己的假公钥，冒充服务端；还可以破解发送端利用假公钥加密的数据后再利用真公钥加密传输给接收端，整个过程中间人不会被察觉；即任何人都可以生成一对公钥和私钥，主动方无法确认请求到的公钥是否是期待的服务器的公钥；
  2. 数字证书：拿到一个数字证书，可以通过某些技术判断这个数字证书是属于谁的，进而可以判断数字证书中的内容是谁发送的；利用数字证书保存公钥代替明文传输公钥，可以让请求公钥者判断请求到的公钥是谁的；

  模拟过程

  ****step1****： “客户”向服务端发送一个通信请求

  “客户”->“服务器”：你好

  ****step2****： “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息，私钥由“服务器”持有

  “服务器”->“客户”：你好，我是服务器，这里是我的数字证书

  ****step3****： “客户”->“服务器”：向我证明你就是服务器，这是一个随机字符串

  “服务器”->“客户”：{一个随机字符串}[私钥|RSA]

  ****step4****：“客户”->“服务器”：{我们后面的通信过程，用对称加密来进行，这里是对称加密算法和密钥}[公钥|RSA]

  “服务器”->“客户”：{OK，已经收到你发来的对称加密算法和密钥！有什么可以帮到你的？}[密钥|对称加密算法]

  “客户”->“服务器”：{我的帐号是aaa，密码是123，把我的余额的信息发给我看看}[密钥|对称加密算法]

  “服务器”->“客户”：{你好，你的余额是100元}[密钥|对称加密算法]

证书与签名

1. 签名：签名是在信息后面加上一段识别信息，可保证接收方识别信息是否被窜改；其是不可逆的，不能通过hash值还原信息；密文传输过程中，攻击者虽不能解密，但可胡乱更改密文，造成真实信息解读发生随机错误；可将信息进行hash计算得到对应的hash值指纹，信息和信息的hash值一同发送给接收方，接收方再次计算信息的hash值同数字签名做对比，判断信息的正确性；若想篡改不被察觉，除非篡改信息后，将原数字签名抹除，更换为篡改信息的对应的新数字签名；{信息+数字签名}这段内容一般是加密的，破坏密文无法定向而精确的修改其中的签名部分；

2. 数字证书认证机构（CA，Certificate Authority）：收信任的证书颁发机构，其真实公钥在操作系统中提前安装

3. 证书的数字签名：CA对申请服务器的个人信息和公钥进行Hash计算得到指纹摘要，再利用自己的私钥进行加密得到数字签名

   CA使用自己的私钥，对申请证书者上传的公钥附加数字签名，并颁发证书

4. 数字证书：

   包括：1.服务器个人信息+服务器公钥；2.上述信息的指纹加密后得到的数字签名

   使用：对1.中信息进行hash，得到指纹；利用事先保存在系统中的真实的CA公钥，解密数字签名2.得到服务器申请时信息的指纹；对比指纹是否匹配，判断证书中公钥的真实性；

   证书具有自己的指纹和指纹算法，其用以验证证书本身在传输过程中是否被篡改

5. 黑客没有CA的私钥，而数字签名是加密的，他无法冒充CA进行签名，伪造的签名会被客户端中CA的公钥解析失败；CA的公钥是工信机构的公开公钥，不会被冒充；除非证书颁发的公司是不受信任的

HTTPS通信的过程

1. 户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。

2. 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

   之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

   最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。

3. SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

   接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

   客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

4. 服务器同样发送 Change Cipher Spec 报文。

   服务器同样发送 Finished 报文。

   服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。

DNS

Domain Name System:域名系统

1. 主机名到ip地址的映射；
2. DNS查询：递归查询+迭代查询；
3. DNS查询使用的协议：UDP协议，因为响应速度快；

顶级域：

二级域：

三级域：www，万维网服务；mail，邮件服务；buaa，教育服务

DHCP

• DHCP(Dynamic Host Configuration Protocol)动态主机设置协议：实现即插即用，自动分配IP地址和子网掩码

• DHCP是一个应用UDP协议的局域网范围的应用层协议

• DHCP服务器：设置需要分配的IP地址、子网掩码、路由控制信息、DNS服务器地址等

• 工作机制：1.发送DHCP发现包请求分配，接受DHCP提供包给予可用设置

  ​ 2.发送DHCP请求包通知使用，接受DHCP提供包通知允许

  DHCP discover->DHCP offer->DHCP request->DHCP positive/negative

  ​ （使用过程中，还有DHCP解除包、DHCP续租请求等其他包）

• DHCP中继代理：各个网段设置中继代理，终极代理单播通讯DHCP总服务器，完成企业规模的DHCP服务

• DHCP服务器的监听默认端口：67

Cookies

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

传输层

作用：建立连接、确保信息到达

套接字：

对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，一个套接字就是网络上进程通信的一端，是支持[TCP/IP协议的路通信的基本操作单元。套接字Socket=（IP地址：端口号）。套接字之间的连接过程可以分为三个步骤：服务器监听、客户端请求、连接确认

端口号：

• 用于识别同一台计算机中进行通信的不同应用程序
• 通信识别的充要ID：源IP地址、目标IP地址、协议号、源端口号、目标端口号
• 端口号确定：静态方法，知名端口号（0_{1023）；时需分配法，操作系统动态分配（49152}65535）

TCP

TCP与UDP的区别

TCP：面向连接的、提供可靠性传输的流协议。实行顺序控制、重发机制，具备流控制、拥塞控制等。

UDP：不具有可靠性的数据报协议，细节交给应用层完成。可确保发送消息的大小，但不保证一定到达。适用于高速、实时性要求的传输或广播

TCP如何保证可靠传输、传输顺序

1. 等待确认、超时重传机制：保证了每一个数据包都能送达；
2. 使用序列号和确认应答：接收端可以根据序列号对数据进行排序，丢弃重复的数据；
3. 校验和：保证数据的正确性；
4. 使用滑动窗口进行流量控制：防止发送过快造成大量丢包；
5. 拥塞控制： 当网络某个节点发生拥塞时，减少数据的发送，防止大量迟到或丢包；

TCP中各种技术的实现方法

1. 超时重传：使用定时器计时
2. 流量控制：接收方返回的 ACK 中会包含自己的接收窗口大小，以控制发送方此次发送的数据量大小（发送窗口大小）。
3. 拥塞控制：慢启动、拥塞避免、快恢复

TCP的滑动窗口有哪些作用

1. 使用滑动窗口一次性发送多个数据包，同时完成多个数据包的确认；
2. 当收到确认应答时，发送窗口滑动到所确认号的位置；
3. 不必为每一个序列号应答的丢失进行重发，收到更大序列号的应答时，代表之前的均以确认，滑动窗口直接滑动，减小了应答信息丢失造成的损失；
4. 选择重传：当有中间数据包丢失时，接收端应答序列号停滞在丢失处，接收端无论收到什么，都会反复应答丢失数据包对应的序列号，发送端收到三次相同的应答序列号，则会重发对应的信息。对于后续已发送的信息，接收端已缓存，在收到选择重传的信息后直接跳过已收到信息的应答，直接告知客户单下一个新信息的序列号是多少；

TCP如何实现流量控制

由于接收端处理数据的速度以及分配的资源有限，应控制发送速率避免大量丢包，造成无效发送

1. 接收端应答时发送窗口大小，控制对方的发送速率。发送方根据该信息动态的调整发送窗口大小。
2. 当收到接收端指示的窗口大小为0时（接收端缓存满了），发送端启动坚持定时器，每隔一段时间发送一个窗口探测报文。

TCP如何实现拥塞控制

发送窗口的大小不仅受制于接收窗口，还需考虑到网络拥塞造成的大量丢包；拥塞控制算法的主要功能是，基于发送方对网络拥塞状况的感知，调节自身发送窗口的大小。

1. 慢启动：从1开始以指数级增长发送窗口，试探网络的拥塞状况。（发送窗口的大小是设置的拥塞窗口与接收方通知的接收窗口中较小值）
2. 拥塞避免：慢启动阀值：发生拥塞（超时重发）时，设置一个慢启动阀值，大小为窗口值的一半。重置发送窗口重新试探，达到慢启动阀值时改为线性增长；
3. 快回复：触发选择重传机制时，有部分可能是网络拥塞造成的，此时慢启动阀值设置为当前窗口的一半，发送窗口不重置，而是直接设置为当前慢启动阀值+3个数据段大小

TCP的报文包含哪些内容

• 机制：对通信进行控制的协议，丢包重发，顺序控制，在确认连接后才发送，对网络层提供可靠性传输保障

• PDU：

• 32bit序号：0~2^32-1，数据首字节序号，一个字节对应一个序号；
• 32bit确认号：期望收到数据的首字节序号，确认号为N，表示N-1序号的数据已经收到；
• 4bit数据偏移：数据偏移首部的距离，由于TCP选项长度不定；
• TCP标记：URG（紧急数据）、ACK（确认位）、PSH（推送位）、RST（重置位）、SYN（同步位）、FIN（终止位）；
• 窗口：指明允许对方发送的数据量；
• 校验和：校验数据；
• 紧急指针：配合URG=1时，指定紧急数据在报文中的位置；TCP选项：最多40byte，支持未来拓展；

TCP三次握手的过程

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

  首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

  在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

• 发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

• 在socket编程中，客户端执行connect()时，将触发三次握手。

• 握手1和2保证接收方可以接受发送方信息并做出正确应答，握手2和3保证发送方能接受接收方信息并做出正确应答，从而实现可靠的全双工通信。

  • 第一次握手：client发送，server收到了；此时server知道：client可发送，server可接收；于是server转换为SYNC-RCVD。
  • 第二次握手：server发送，client收到了，此时client知道：client发送、接受均正确，server发送、接受均正确；于是client转换状态为ESTABLISHED。server仍只知道：client可发送，server可接收；
  • 第三次握手：client发送，server收到了；此时server才知道：client发送、接受均正确，server发送、接受均正确；于是转换状态为ESTABLISHED。全双工通信建立成功

若没有第三次握手会导致什么？

1. 不能确认服务器是否可以正常发送数据，建立不正常的连接
2. 服务器不能判断第二次握手是否成功，server在收到第一个SYN包后建立连接，而此后若收到失效的SYN报文（如早发而堵塞延时到达）则会引发错误

第三次握手失败怎么办？

client发送ACK包后就进入了ESTABLISHED状态，执行发送数据的任务。而此时会受到RST包响应，感知到server连接未建立；

server未收到ACK包，则根据超时重传，等待3s、6s、12s后重发SYN+ACK包，次数默认为5，超过指定次数后server自动关闭该连接。期间server会受到client发送的数据报，server以RST包响应；注意，在默认重传5次情况下，服务器被占用1+2+4+8+16+32=63s才会放弃连接进入CLOSED状态

半队列连接是什么

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

ISN(Initial Sequence Number)是什么

初始化的seq，seq作为的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输的问题而乱序；ISN随时间动态生成，使得攻击者不易猜中

三次握手过程中可以携带数据吗？

只有第三次可以，此时client是ESTABLISHED状态，知道双发均正确，因此可以携带数据。第一次不可携带数据，若server理会第一次握手中的数据，会容易被恶意攻击，缓存大量恶意攻击数据包内容，导致崩溃

SYN攻击是什么

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。

Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，而由于IP虚假，三次握手始终失败，使得server被大量无效的半连接占用。

TCP四次挥手

• 第一次挥手：client发送一个 FIN 报文，告知server自己不会再发送通讯数据，并指定一个序列号。此时client处于 FIN_WAIT1 状态，等待server服务端的确认。
• 第二次挥手：server收到 FIN 之后，会发送 ACK 确认报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，告知client你方发送通道已关闭，此时服务端处于 CLOSE_WAIT 状态。此时的TCP处于半关闭状态，client到server的连接释放。client收到server的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 连接释放报文，告知自己不会在发送通讯数据，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。
• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。通过等待计时器等待2MSL后，未收到server的重发数据，确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

为什么需要四次挥手？

通信建立时，server的ACK与SYN同时发送。 TCP 不允许连接处于半打开状态时就单向传输数据，因此想通讯就建立全双工通道

连接释放时，ACK与FIN分开发送。 TCP 的双向通道互相独立，连接处于半关闭状态时，TCP 是允许单向传输数据的。主动方client发送数据完成时，被动方server也许还有数据未发送完，因此在FIN-WAIT-2/CLOSE-WAIT时间段内，server完成收尾工作，完成后再发出FIN信号。

TCP粘包问题

什么是TCP粘包

TCP使用流式传输，没有消息边界的保护，发送消息时粘连，导致接收端收到的消息数目小于发送的消息数目；

1. 正常情况下：接受方收到两个数据包，内容Msg1和Msg2的完整信息，只需分别读取进行消费
2. 粘包问题：接收方收到一个数据包，内容是Msg1和Msg2的粘连，接收端无法区分两条消息的边界
3. 粘包加拆包问题：接收方受到了两个数据包，包括Msg1的完整信息和部分Msg2信息，Msg2的剩余信息；反之同理；

为什么发生粘包与拆包

1. 发送方写入的数据小于套接字缓冲区大小，由于 TCP 默认使用 Nagle 算法，只有当收到一个确认后，才将分组发送给对端，当发送方收集了多个较小的分组，就会一起发送给对端，这将会发生粘包。
2. 发送方发送的数据太快，接收方处理数据的速度赶不上发送端的速度，将发生粘包。
3. 发送方写入的数据大于套接字缓冲区的大小，此时将发生拆包。
4. 进行 MSS （最大报文长度）大小的 TCP 分段，当 TCP 报文的数据部分大于 MSS 的时候将发生拆包。
5. UDP有消息保护边界，不会发生粘包问题

什么时候需要处理粘包问题？

当接收端同时收到多个分组，并且这些分组之间毫无关系时，需要处理粘包；

而当多个分组属于同一数据的不同部分时，并不需要处理粘包问题。

如何处理消息粘包

1. 头部标识消息长度信息，服务端获取消息头的时候解析消息长度，然后向后读取相应长度的内容。
2. 设置定长消息，服务端每次读取定长内容作为完整的消息
3. 设置消息边界，也可以理解为分隔符，服务端从数据流中按消息边界分离出消息内容，一般使用换行符。

UDP

UDP的报文包括哪些

• 机制：听什么说什么，按照程序员的编程思路指示行事

• 应用：包总量少的通信（DNS、SNMP）；即时通信（视频、音频）；限定与LAN等特定网络中的应用通信；广播通信；

• PDU：

  

  UDP报文中包含UDP的长度，是一种数据报协议，接收端可分辨数据报的边界，不会发生粘包问题

UDP如何实现可靠通信

通过应用层来实现。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。

网络层

确定数据在网络中的地址（数据路由）：实际网络抽象为虚拟网络，只关注网络层数据转发而屏蔽底层细节，解决虚拟网络中数据包传输的路径问题，实心终端点对点的通信

IP协议

IP寻址、路由、IP分包与组包

IP地址

IP地址：共32位，点分十进制表示，分为4个8位，192.168.11.11=11000000.10101000.0000101.00001011

网段：网络中使用同一物理层设备直接相连的部分

网络标识+主机标识：192.168.128.10/24标识前24位为网络号（192.168.128），10为主机号。网络标识是网段的标识，主机标识是同一网段中区分各个主机的标识，路由器识别网络标识进行转发

IP地址分类：

• A类（0首）：0.1.1.1~127.1.1.1，8位网络标识、24位主机标识，各组实际可容纳主机16,777,214个
• B类（10首）：128.0.0.1~191.255.0.0，16位网络标识、16位主机标识，各组可容纳主机65,534个
• C类（110首）：192.168.0.0~239.255.255.0，24位网络标识、8位主机标识，可容纳主机254个
• D类（1110首）：224.0.0.0~239.255.255.255，32位网络标识，无主机标识，常用于广播

使用子网掩码划分：

（对网络标识位的扩充）

某B类地址：172.20.100.52 （10101100.00010100.01100100.00110100）

子网掩码 ： 255.255.255.192 （11111111.11111111.11111111.11000000）六位主机码

主机地址全0表示对应网络地址不可获知，全1表示广播地址

本地广播：路由器设置为不转发，屏蔽主机号为全1的IP包，广播内容只在当前网段内

直接广播：路由器转发，可以从一个网段发送信息向另一个网段进行广播

IP多播：可以穿路由器的1对N通信

路由控制

• 路由控制表：只记录下一跳的目的地，静态路由控制为手动设置，动态路由控制为动态刷新，路由控制表的制作遵循“路由协议”。

  

• 最长匹配：查路由表多条路径，选择下一个路由器地址与IP地址最长匹配的那条

• 几个特殊的路由地址：

  • 默认路由：都可匹配的一条
  • 主机路由：IP/32，IP所有位全参与路由的地址
  • 环回地址：同一台计算机程序之间进行网络通信的默认地址。127.0.0.1，主机名localhost，不会流向网络

转发流程

总结：数据帧每一条MAC地址都在变化而IP数据报每一跳IP地址不变

若路由表中没有映射

路由器对除发送源外的端口进行广播，并收到所有设备回应，记录并更新路由表填充缺失信息

ARP与RARP

• ARP：IP地址->MAC地址
• RARP：MAC地址->IP地址

数据链路与物理层

实现比特流的透明传输。

主机之间的通信方式

• 单工通信：也叫单向通信，发送方和接收方是固定的，消息只能单向传输。例如采集气象数据、家庭电费，网费等数据收集系统，或者打印机等应用主要采用单工通信。
• 半双工通信：也叫双向交替通信，通信双方都可以发送消息，但同一时刻同一信道只允许单方向发送数据。例如传统的对讲机使用的就是半双工通信。
• 全双工通信：也叫双向同时通信，全双工通信允许通信双方同时在两个方向上传输，其要求通信双方都具有独立的发送和接收数据的能力。例如平时我们打电话，自己说话的同时也能听到对面的声音。

通道复用

• 时分复用
• 频分复用
• 波分复用
• 码分复用