计算机网络概念整理

---

1、协议：

是网络交互的基础，是一种约定，规范双方的通讯行为用于保证网络传输双方能够正常通讯

2、协议的分层

（1）OSI 七层模型（从上到小的，下一层是为上一层服务的）

• 应用层 ：将标准的数据转换成程序需要的格式
• 表示层：将设备的数据格式转化成标准的格式。
• 会话层：用来管理通讯双方之间的会话。
• 传输层：用来确保双方的数据可以正常传输
• 网络层：地址的管理和路由的选择
• 数据链路层：保证相邻节点之间的数据传递
• 物理层：将数字信号传递成为光电信号

（2）TCP/IP 四层模型

• 应用层：常用协议有 —— HTTP(80)、FTP(21)、SSH(22)、TELNET(23)、DNS(53)
• 传输层：常用协议有 —— TCP、UDP
• 网络层
• 数据链路层

3、传输层详解

（1）数据传输的5各要素：

• 1、源地址IP
• 2、源地址端口号
• 3、目的地IP
• 4、目的地端口号
• 5、协议类型

（2）IP地址与MAC地址：

• IP地址的作用是在网络中确定一个位置，IPv4的长度为32位
• MAC的作用是在局域网中确定位置，MAC的长度为48位

（4）UDP传输协议：

• 1、无连接

• 2、不可靠

• 3、面向数据包
  

• UPD可以创数的最大长度为 65535 -> 64K ，并且这64K是包含头部的8字节的

• UDP没有发送缓冲器，有接收缓冲区，有信息就直接发，不往缓冲区里放，不管接受方的接受能力

• UDP的使用场景：DNS、NFS

（5）TCP传输协议：

• 32位序号和32位确认序号都是为了标识当前TCP的消息的，相当于它的主键，为了在ACK消息应答时使用
• 4位首部长度就是头部的长度
• 6位保留信息中，存放的都是 0 或者 1
  - 当ACK等于 1 时，表示这条消息是 客户端 返回给 服务器端 的 确认应答消息
  - SYN 是在三次握手中使用的序列号
  - FIN 是在断开连接四次挥手时 第一次挥手时会加上的信息（第一次挥手时，客户端就会给服务器端发送一个FIN）
  - UDG 标识当前数据为一个紧急指针，与后面16位的紧急指针一同起作用，16位的紧急指针用来表示那一部分的数据时紧急数据
  - PSH 告诉接收端，尽快把接收缓冲区中的数据取出来，会发生在拥塞控制
  - RST 复为指针，当网络不稳定的情况下，有可能会去重新建立连接
• 16位窗口大小，指的是接收缓冲区的窗口大小，用作拥塞控制。
  当接收端消费能力强的时候，接收缓冲区的窗口是比较大的，反之比较小，它是在不停变化的，所以要每次传输的时候都带上。用于告诉下一次发送消息时，多发还是少发。
• 16位效验和，用于效验发送前和发送后数据的正确性和完整性.
  

4、TCP十大特性：

1、确认应答：是TCP和UDP最大的区别

• 当有消息发送来之后，我会给你回复一个响应，保障稳定性最关键的措施

2、超时重传：为了解决 消息没有发到服务器端 或 服务器端的响应ACK丢失

• 重传策略：
   a) 动态的重传频率，每一次会在上次的时间上 × 2
   b) 当重试一定次数之后，还没有成功，就会停止超时重传

3、连接管理（TCP的稳定性保障）

 三次握手

  为什么需要三次握手，两次行吗？
  答：三次握手的主要原因是为了验证客户端和服务器端的手法能力，当二者都具备收法能力才可以（全双工 —— 即要去发送，也要去接受）。由于发送端的发送能力要让接收端来告诉，不能自己和自己验证，所以要经过三次验证才能验证双发的发送和接受能力。如果两次的话，是不能完全验证双方的能力的
  在三次握手的这个过程中，状态发生了什么变化？交互过程中交互的是哪些数据？
  答：初始情况下，客户端TCP和服务器端TCP都是 CLOSE 状态
    当客户端TCP启动后，客户端的状态会变成 LISTEN 状态，此时服务器端允许其他的客户端连接它
    客户端第一次握手时，给客户端发送一个 SYN ，并且自身的状态变成 SYN_SENT（序列号的发送状态），此时服务器端的状态从监听状态就变成为 SYN_RCVD（序列号确认状态）
    服务器端第二次握手，将 SYN 加上 ACK 的确认信息回复给客户端
    客户端如果接收到信息就会变成 ESTABLISHED 状态，此时会第三次握手，会再发送一个ACK确认信息给服务器端，服务器端接收到这个ACK信息后会变成ESTABLSHED状态
    此时双放就可以进行通讯了

 四次挥手

  三次握手一定需要三次，但四次挥手不一定需要四次，有可能三次挥手收也能搞定（依赖于TCP的捎带应答特性），当服务器端收到客户端挥手想要断开连接的FIN时，服务器端会查看自己的接收缓冲区，如果此时的接收缓冲区为空，服务器端就可以将返回的应答ACK与下一次要发送的FIN合并为一个请求，捎带的发送给客户端，客户端收到这两个消息后在去发送ACK应答给服务器端，二者就可以断开连接
  标准的四次挥手流程如下：
    首先，在客户端要和服务器端断开连接时，客户端会发送一个FIN给服务器端，并且将自己的状态从ESTABLISHED变成FIN_WAIT_1（第一次等待断开连接状态）
    然后，服务器端接收到FIN后，就会从 ESTABLISHED 变成 CLOSE_WAIT 状态，然后再去发送一个 ACK 应答给客户端
    接着，当客户端接收到服务器端发送来的ACK应答后，它的状态就从FIN_WAIT_1变成FIN_WAIT_2，此时服务器端就会等待客户端给他发送彻底断开连接的指令
    再者，当服务器端处理完接收缓冲区的数任务，会发送一个FIN给客户端，并将自己的状态置于L;AST_ACK（最后一次确认）
    最后，当客户端拿到服务器端给他的FIN后，服务器端就知道客户端已经做好了销毁连接的准备了，此时服务器端会再次发送一个ACK给服务器端，并进入TIME_WAIT状态，且在这这个TIME_WAIT状态上等待两个MSL（最大等待时间），这是为了防止客户端发送给服务器端的响应ACK丢失了，如果客户端ACK丢失了，服务器端会再发送一个FIN各客户端，此时客户端就需要等待两个MSL看看客户端是否正常收到了断开的ACK响应。

4、滑动窗口（高效的进行数据的传递）

• 一次一批一批的发送数据

• 快重传机制：每次服务器端给客户端响应的ACK都是最大的ACK。如果小的ACK丢失了，会等小的ACK补全之后就可以接收到下一轮的任务。

滑动窗口是越大越好吗？
  答：当滑动窗口设置的越大，信息在传递的时候吞吐量就越大，一次需要传递的内容就越大，如果传输的信息比较多，而接收端的接受能力比较弱，就会导致接收缓冲区以爆满，会导致信息的舍弃，无法进行消息的应答，导致触发大量的超时重传，形成恶循环.

5、流量控制

  流量控制是会查看接收缓冲区的大小，发送消息时，将这个大小放在消息头中的16位窗口大小中，客户端拿到这个值后，根据这个值决定下次传递多少数据，但它传递的最大值是不会超过滑动窗口的值的
  当接受大小缓冲区为0时：
   （1）停止消息发送
   （2）发送检测包，每隔一段时间去询问接受端的接受缓冲区大小

6、拥塞控制

  会根据网络情况决定发送数据的多少

  一开始，不清楚此时网络情况是否良好的情况下，会进行“慢开始”，少量的发送一些数据包试探一下。在发送的过程中的发送速度有一个阈值（ssthresh），假设一开始阈值为16，在未满足阈值之前，发送速度以指数型增长。当到达阈值后，会从指数级变成线性增长的（16，17，18，…），当发送速度逐渐增大直至 出现丢包 的情况时，会将发送速度恢复成初始最小值，此时将丢包时的发送速度的一半作为新的阈值，以此往复

7、延迟应答（提升性能）

  当消息到达服务器端，服务器端首先会查看接收缓冲区的大小，并将服务器端接收缓冲区所剩的大小告诉客户端。但是在这个消息到达客户端的过程冲，有可能服务器端的接收缓冲区中的数据被消费掉了，空间变得更大了；所以要用到延迟应答
  延迟应答的策略：
    （1）每隔一定次数之后，延迟应答一次；
    （2）每隔一段时间，延迟应答一次；
  **注意事项：**延迟应答的时间(200ms)不能超过超时重传的时间（500ms）。

8、捎带应答（进一步提升性能）

  发送端想要告诉给接收端的消息变多了，合并这些消息，让它进行捎带应答
  能够实现三次挥手的重要机制。

9、面向数据流

  粘包/半包 问题
  解决方案：
  （1）以固定的大小的传输包去发送消息（缺点：造成不必要的网络开销）
  （2）使用结束符来明确消息边界。

10、TCP异常处理

  没有缓冲时间异常（断电、断网）【TCP 健康检测机制 —— 多次检测，若是没有检测到在线，就会关闭连接】
  有缓冲的异常：正常关机【和正常的断开连接是一样的，四次挥手】

面试题1：当输入一个URL之后会发生什么？

（1）效验URL正确性 —— 浏览器的行为（不正确则显示错误页面）
（2）检测本地缓存
（3）访问DNS服务器，实现域名解析 —— 获得所访问页面的 IP 和 端口号
（4）建立TCP链接（三次握手）。
（5）浏览器会将参数和请求信息发送给服务器端。
（6）服务器得到请求的参数信息，然后再进行业务处理。 —— 服务器端查询数据库/操作数据库
（7）服务器将信息返回个客户端
（8）浏览器拿到响应的信息之后，通过浏览器的执行引擎解析结果并且展示给用户。
（9）TCP是短链接，所以会进行链接断开（四次挥手）

面试题2:Post与Get相关问题

  1、Get与Post的区别

   -  Get的请求参数有长度限制，而Post没有长度限制
   -  Get直接将参数暴露在URL上，更加不安全，Post放在Request Body中
   -  Get只接受ASCII字符的参数数据类型，Post没有限制
   -  浏览器的历史纪录中会保存完整的Get请求参数，而Post不会被保存

  2、Get请求有Request Body，吗，能否将请求参数放在里面？

   Get请求和Post请求都是TCP连接的方式，所以两者能做的事是完全一摸一样的，只是规定上Get请求不允许在RequestBody中写参数。
   所以Get请求是有RequestBody的，并且也可以将参数放在里面，但是根据服务器的不同，有的服务器会将Get请求中的RequsetBody读出来，有的会直接忽略

  3、Get、Post请求发送的数据包有什么不同？

   -  Get请求，发送一个TCP数据包，将http header 和 data 一起发出去，服务器响应为200
   -  Post 请求，发送两个TCP数据包，先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200

面试题3:Http与Https相关问题

  1、Http与Https有什么不同

   -  Http协议以明文方式发送内容，不提供任何方式的数据加密；运行在TCP上
   -  Https协议在其Http的基础上加入了SSL协议来验证服务器身份，对浏览器和服务器之间的通信加密；运行在SSL/TLS上，而SSL/TLS同样是运行在TCP之上 —— 主要作用:（1）建立一个信息安全通道；（2）确认网站真实性

  2、Https的工作原理？

   （1）客户端URL访问Web服务器，请求与服务器简历SSL链接；
   （2）Web服务器收到请求后，将网站的证书信息（包含公钥）发送给客户端
   （3）客户端确定SSL连接的安全等级（信息加密等级）
   （4）客户端根据最终确定的安全等级，建立会话密钥，使用服务器端传过来的公钥对密钥进行加密，并发送给服务器端
   （5）服务器端使用自己的私钥解密客户端发送来的密钥
   （6）利用密钥实现客户端与服务器端加密通讯
  
—— 上述流程中用到了 对称加密 和 非对称加密

  3、什么是对称加密、非对称加密？

   -  对称加密： 使用同样的密钥，进行加密与解密
   -  非对称加密：
       加密：原文 + 密匙 = 密文
       解密：密文 - 密匙 = 原文
                  
  非对称加密有两个钥匙，公钥和私钥，两者是成对存在的，原文使用公钥加密，就要使用私钥进行解密
  在Https的例子中，因为私钥只有服务器端自己持有，所以用公钥加密后，之后服务器端的私钥可以进行解密。

面试题4:Session与Cookie相关问题

   -  Cookie，在客户端记录信息确认用户身份

  Http是一种无状态协议（一旦数据交换完毕，就会关闭连接，再次交换就要重新建立连接），服务器从网络连接上无从知道客户端的身份（无法跟踪），所以服务器给客户端每人发一个通行证，每个人访问时都必须携带通行证，服务器端从通行证上确认客户端的信息（同时也在里面记录状态信息），这就是Cookie的工作原理；

   -  Session，在服务器端记录信息确认用户身份

  Session机制是通过检查服务器上的”客户明细表“来确认客户身份，这个表上的内容就是要确认SessionID的信息；如果禁用了Cookie，就得不到Session，因为Session ID 是通过Cookie传递的；

  如何预防本地用户禁用了Cookie后影响到浏览器的Session不能使用？

  将SessionId 记录在url中，每次都传递他，这样他就不会丢失

  Session VS Cookie

1、Cooklie 保存在客户端；Session保存在服务器端
2、Session 的实现是依赖 SessionId的，而SessionId 是存储在 Cookie中，所以如果禁用了Cookie那么整个Session机制也不能使用
3、Cookie有大小限制，为了防止网络传输中的负担，一般最大值为4K；
4、Cookie在本地容易被串改，而Session在客户端，通常情况下Session比Cookie更加安全

    
    
以上内容部分来自_陈哈哈