计算机网络基础知识点整理

OSI与TCP/IP各层的结构与功能

五层协议

• 应用层：为特定应用程序提供数据传输服务，例如HTTP、DNS等协议，数据单位为报文。
• 传输层：为进程提供通用数据传输服务。由于应用层的协议有很多，定义通用的传输层协议可以支持不断增多的应用层协议。包含两种传输协议，用户数据报协议（UDP）和传输控制协议（TCP），UDP提供无连接的、尽最大努力交付的数据传输服务；TCP提供面向连接的、可靠的数据传输服务。
• 网络层：为主机提供数据传输服务。网络层的任务是选择合适的网间路由和交换节点，确保数据到达对方计算机。在发送数据时，网络层负责把运输层的报文段或者用户数据报封装成分组（IP数据报）。
• 数据链路层：网络层针对的是主机之间的数据传输，但是主机之间可以有很多链路，数据链路层就是为同一链路的主机提供数据传输服务。链路层上网络层的分组封装成帧。
• 物理层：所传输的数据单位是比特，其作用是尽可能屏蔽掉传输介质和物理设备的差异，让数据链路层感受不到这些差异。

为什么要分层

• 优点
  • 使网络变得更简单和标准化
  • 有利于模块化设计
  • 保证不同类型部件的互操作性
• 缺点
  • 有些功能，比如流量控制会在每一层上重复出现，降低了系统的效率。
  • 层次和数量不是最佳的，比如会话层和表示层基本是空的，但是网络层包含的内容太多。

应用层

HTTP

HTTP请求方法

请求方法种类

1. get

   请求资源

2. post

   提交实体的主体

3. put

   上传文件

   自身不带校验机制，任何人都可以上传文件，存在安全性问题。如果结合web的校验机制或者REST标准，可以放开此方法。

4. delete

   删除文件

   自身不带校验机制，任何人都可以上传文件，存在安全性问题。如果结合web的校验机制或者REST标准，可以放开此方法。

5. head

   和get方法类似，但是值返回报文的首部

6. options

   返回url支持的方法

7. trace

   将通信路径返回给客户端

8. patch

   与put的功能类似，但是能对资源部分修改

9. connect

   要求与服务器建立隧道

   基于SSL或者TLS把通信内容加密后经网络隧道传输

get和post区别

1. 从功能上来说：get是请求资源，post是向服务器提交资源。
2. 安全性方面：get请求的内容是暴露在url地址中；post请求提交的内容隐藏在请求体中。
3. 从服务上看：get请求时幂等，多次请求不会改变服务器上的资源；post请求不是幂等的，每次请求都会改变服务器上的资源
4. 请求形式：get请求的内容是位于请求头，附在url地址后面，用?号分隔，参数用&连接；post请求提交的内容是在请求体中。
5. 请求大小：get请求的长度受浏览器对url长度的限制；post的大小不受限制。

HTTP报文结构

请求报文

• 请求行：请求的方法，URI和HTTP版本
• 首部字段
• 报文主体

响应报文

• 状态行：响应结果的状态码，原因短语和HTTP版本
• 首部字段
• 报文主体

HTTP响应状态码

1XX 信息

100：表示到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

1. 200：OK

2. 204：请求已经处理，但是返回的响应报文不包含实体的主体部分

3. 206：表示客户端进行了范围请求，响应报文包含由content-range指定范围的实体内容

3XX 重定向

1. 301：永久重定向
2. 302：临时重定向
3. 303：和302有着相同的功能，但是303明确要求客户端应该采用get方法获取资源
4. 304：如果请求报文首部包含一些条件，例如if-match，if-modified-since，如果不满足条件，则服务器返回304状态
5. 307：临时重定向，与302含义类似，但是307要求浏览器不会把临时重定向的post方法改成get方法

4XX 客户端错误

1. 400：请求报文中存在语法错误
2. 401：表示发送的请求需要有认证信息。如果之前已进行过一次请求，则表示用户认证失败。
3. 403：请求被拒绝
4. 404：未找到资源

5XX 服务端错误

1. 500：服务器正在执行请求时发生错误
2. 502：网关错误
3. 503：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

HTTP长连接和短连接

HTTP的长短连接本质是TCP协议的长连接和短连接。

• HTTP1.0默认使用短连接，也就是说客户端和服务器每进行一次HTTP操作，就建立一次连接。

• HTTP1.1默认使用长连接，响应中加入connection：keep-alive，使用长连接的情况下，当网页打开完成时，tcp连接不会关闭，客户端再次访问服务器时，会继续使用这一条已经建立的连接。

  长连接不会永久保持连接，它有一个保持时间，可以在不同的服务器软件中设定这个时间。

HTTP1.0、1.1、2.0

HTTP1.0和HTTP1.1的区别

1. 长连接。

   HTTP1.1默认使用长连接，一个TCP连接可以发送多个请求，减小了关闭和建立连接的消耗与延迟。

2. host头的处理。

   HTTP1.0默认每台服务器绑定唯一的ip，因此请求的消息中没有传递主机名。但是随着虚拟技术的发展，一个屋里服务器可以存在多个虚拟主机，并且他们共享一个ip地址。HTTP1.1的请求消息中如果没有HOST头信息会报错

HTTP1.0和HTTP2.0的区别

1. 多路复用。

   HTTP2.0多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其他连接的正常执行。

   HTTP1.1是若干个请求串行化单线程处理，后面的请求等待前面的请求返回才能获得执行机会

2. 新的二进制格式

   HTTP1.X是基于文本，由于文本的表现形式有多样性，要做到健壮性要考虑的场景很多。二进制格式方便且健壮。

3. header压缩

   HTTP1.X的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小。

4. 服务端推送

   服务端在http请求到达后，除了返回数据之外，还推送额外的内容给客户端。

HTTPS

HTTPS的理解（SSL和TLS）

HTTP协议的不足：

1. 通信使用明文（不加密），可能会被窃取
2. 不验证通信方的身份，因此可能遭受伪装
3. 无法验证报文的完整性，有可能已遭篡改

HTTPS使用了隧道进行通信，先让HTTP与SSL进行通信，再让SSL与TCP进行通信。

HTTP+认证+加密+完整性保护=HTTPS

加密

• 对称密钥加密：加密密钥和解密密钥都是同一密钥

  优点：运算速度快

  缺点：无法安全的将密钥传输给通信方

• 非对称密钥加密：

  加密和解密使用不同的密钥，公钥所有人都可以获得，发送方获得接受方的公钥之后，使用公钥进行加密，接收方收到之后就使用私钥进行解密。

  非对称加密还可以用于签名，可以用来判断签名是否正确。

  优点：可以安全的将公钥传输给发送方

  缺点：运算速度慢

• HTTPS加密方式

  HTTPS采用混合加密的方式，使用非对称加密来发送对称密钥，来保证传输的安全性，之后使用对称加密通信来保证通信的效率。

认证
通过使用证书来对通信方进行认证。数字证书认证机构CA是客户端和服务端双方都可新来的第三方机构。

完整性保护

提供报文摘要来进行完整性保护。

HTTP和HTTPS的区别

• HTTPS协议需要申请到CA证书，一般免费证书很少，需要交费
• 资源消耗：HTTP是超文本传输协议，明文传输；HTTPS是具有安全性的TLS加密传输协议，需要消耗更多的CPU和内存资源
• 端口不同：HTTP协议是80端口；HTTPS协议是443
• 安全性：HTTP明文传输不安全，同时是无状态的，不验证通信方的身份；HTTPS是TSL+HTTP组成的加密，认证的网络协议。

HTTPS过程

1. 首先客户端会将支持的加密协议和版本发送给服务端
2. 服务端从中筛选出合适的加密协议，并且把证书发送给客户端，证书中包含公钥
3. 客户端收到证书之后会验证证书合法性，通过公钥加密一个共享密钥，将加密的共享密钥发给服务端
4. 服务端接收到共享密钥之后，使用私钥进行解密，之后就可以利用这个共享密钥进行通信加密了。

DNS的解析过程

递归查询

主机向本地域名服务器查询采用递归查询。

递归查询：如果本地域名服务器不知道被查询的域名ip地址，那么本地域名服务器就会向根域名服务器继续发出查询（替主机查询），而不是让主机自己查询。

迭代查询

本地域名服务器向根域名服务器查询采用迭代查询。

迭代查询：根域名服务器收到本地域名服务器发出的迭代查询请求之后，要么给出所要查询的ip地址，要么告诉本地服务器下一步该向哪一个域名服务器进行查询。

域名缓存

主机和本地域名服务器中使用了高速缓存，用来存放最近查询过的域名以及何处获得域名映射信息的记录。

传输层

TCP和UDP

TCP和UDP的区别

• TCP

1. 面向连接的。
2. 面向字节流。TCP发送报文时，是将应用层数据写入TCP缓冲区中，然后由TCP协议来控制发送这里面的数据，而发送的状态是按字节流的方式发送的。
3. 提供可靠交付的服务。通过TCP连接传送的数据无差错、不丢失、不重复、并按序到达。
4. TCP提供一对一的全双工通信，TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接受缓存，用于临时存放双方通信的数据。
5. TCP的首部20个字节，包括序号，确认号，数据偏移，确认ACK，同步ACK，终止FIN，窗口

• UDP

1. 无连接的。
2. 面向用户数据报，不会对报文进行拆分或者合并。
3. 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态。
4. UDP支持一对一，一对多，多对一，多对多的交互通信
5. UDP的首部开销小，只有8个字节，包括源端口，目的端口，长度，校验和。

TCP和UDP的使用场景

UDP和TCP的区别体现在是否连接，报文，可靠性，双工性、效率等几个方面。

• TCP

  对效率要求相对低，但对准确性要求较高的场景

  应用示例：TCP一般用于文件传输（应用层协议如FTP，HTTP对数据准确性要求较高）；发送或者接受邮件（SMTP，POP协议）；远程登录（telnet）。

• UDP

  对效率要求较高，但是对准确度要求相对低的场景

  应用示例：DNS协议，用于即时通信，语音，直播等

TCP三次握手和四次挥手

相关概念：

ACK：确认收到

FIN：请求关闭报文

SYN：请求建立连接

MSL：最大报文生存时间

三次握手

最开始客户端和服务器都处于CLOSED的状态。

• 第一次握手

  客户端向服务端发送请求报文，SYN=1，ACK=0

• 第二次握手

  服务端收到连接请求报文，如果同意建立连接，则向客户端发送连接确认报文，SYN=1，ACK=1

• 第三次握手

  客户端收到连接确认报文，还有向服务端发出确认；服务端收到确认后，连接建立。

为什么是三次握手，而不是两次握手或者四次握手

• 不可以两次的原因：

  为了防止失效的连接请求报文发送给了服务端。如果只有两次，那么服务端在收到失效的连接请求报文之后，误以为客户端又发出一次新的连接请求，从而同意建立连接，这样就造成资源的浪费。

• 不需要四次的原因：

  完全可靠的通信协议是不存在的，经过三次握手之后，客户端和服务端已经确认之前的通信状态，都收到了确认信息。

TCP四次挥手

• 第一次挥手

  客户端发送释放连接请求，FIN=1

• 第二次挥手

  服务端收到之后确认，此时TCP处于半关闭状态。服务端能向客户端发送数据，但是客户端不能向服务端发送数据。

• 第三次挥手

  当服务端不需要连接时，发送连接释放报文，FIN=1

• 第四次挥手

  客户端收到后发出确认，进入TIME-WAIT状态，等待2MSL（最大报文存活时间）后释放连接；服务端收到确认后释放连接。

为什么在TIME-WAIT状态必须等待2MSL的时间？

客户端在收到服务器发送的FIN报文之后，会等待2MSL的时间，主要是有两个理由：

• 为了确保最后一个确认报文能到达，如果服务端没有收到客户端发送来的确认报文，那么会重新发送连接释放请求报文，等待这个时间就是为了处理这种情况的发生。
• 为了让本次连接中所有报文从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

为什么第二次和第三次不能合并？

服务器收到释放连接请求报文之后就进入close-wait阶段，这个状态是为了让服务器端发送还未发送完毕的数据，传送完毕之后，服务器会发送FIN连接释放报文。

TCP如何保证可靠传输

超时重传

接受方在超时时间内没有给发送方发送确认报文，那么发送方就会重传这个报文。

流量控制

流量控制是基于滑动窗口来实现的。接收方会在报文的首部字段设置窗口值，告诉发送方自己的窗口大小，接受方会根据这个值来设置自己的窗口大小。（窗口是缓存的一部分，用来存放字节流，接收方和发送方各有一个窗口）

流量控制主要是为了控制发送方的速率，让接受方来得及接收。

拥塞控制

拥塞控制主要是作用于整个网络，TCP通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方会维护一个**拥塞窗口（cwnd）**的状态变量，拥塞窗口和发送方窗口的区别：发送方窗口决定的是发送方实际能发送多少数据；拥塞窗口只是一个状态变量。

• 慢开始和拥塞避免

  发送最初执行慢开始，令cwnd=1，发送方只能发送1个报文段；当收到确认后，将cwnd加倍。

  加倍使得cwnd增长速度非常快，从而使得发送方发送速率增长非常快，网络拥塞的可能非常大。设置一个慢开始门限，当大于这个慢开始门限的时候，进入拥塞避免，每个轮次只将cwnd加1。

• 快重传和快恢复

  接受方每次要对最后收到的一个报文进行确认，如果收到三个重复确认，说明下一个报文段丢失，执行快重传。

  但是由于快重传只是丢失一个报文，不是网络拥塞，所以执行快恢复，直接进入拥塞避免。

网络层

路由器

路由器从功能上可以划分为路由选择和分组转发。

其中路由选择协议都是自适应的，能随网络通信量和拓扑结构的变化而自适应地进行调整，路由选择协议可以划分为两大类：

• 自治系统内部的路由选择
  • RIP：基于距离向量的路由选择协议，距离是指跳数
  • OSPF：开放最短路径优先
• 自治系统间的路由选择
  • BGP：边界网关协议

ARP协议

ARP协议实现由IP地址得到MAC地址。

当源主机要发送一个数据包到目的主机时，会首先检查自己的高速缓存中有没有IP地址到MAC地址的映射，如果有就直接将这个数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播段，查询此目的主机对应的MAC地址。

数据链路层

交换机

MAC地址

补充

在浏览器输入URL地址到显示主页的过程

1. DNS解析：通过DNS协议查询域名对应的IP地址，首先会查找本机的DNS缓存，若为查询到就会向本地DNS服务器进行递归查询，若本地DNS服务器未查询到，那么将会向根服务器进行迭代查询。
2. TCP连接：浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立连接，发起三次握手
3. 发送HTTP请求：TCP连接建立起来后，浏览器向服务器发送HTTP请求
4. 服务器处理并返回HTTP报文：服务器收到这个请求，并根据特定参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
5. 浏览器解析渲染页面：浏览器解析并渲染视图，向用户呈现一个完整的页面
6. 连接结束

Cookie和Session

Cookie和Session都是客户端和服务端之间保持状态的解决方案，Cookie机制采用的是在客户端保持状态的方案，Session采用的是在服务器端保持状态的方案。

Cookie

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录状态，那么就会通过response颁发一个cookie给客户端，客户端会把这个Cookie保存起来。当客户端下次访问服务器时，就会把这个Cookie带上，服务器通过验证这个Cookie的值来辨别用户状态。

Session

服务端通过Session来保存会话状态。服务端会用SessionId和每个Seesion关联，如果客户端第一次访问服务器，服务器会创建一个Session来记录状态，并且把SessionId颁发给客户端，当客户端下次访问时，就可带上这个SessionId，服务端通过这个id来辨别用户状态。

Session存放的几种方案

1. 存在内存中。用SessionId标识用户，这样的Session十分依赖cookie。如果浏览器禁用了cookie，那么改方案不起作用。
2. 将Session内容存放在cookie中，但前提是经过了加密，然后下次服务器对其进行解密，但是这样浏览器需要维护太多内容了。
3. 当用户登录或者执行某些操作时，使用用户的一部分字段信息进行加密算法得到一串文字成token，作为唯一标识，用户提交请求时必须带上这个token，就可以确认用户信息以及操作是否合法了。

Cookie和Session的区别

1. 实现机制：Cookie保存在客户端，Session保存在服务端，但是Session也依赖于cookie机制，需要通过cookie回传SessionId。
2. 安全性：Cookie存在安全隐患，通过拦截或者本地文件找到cookie后可以进行攻击；Seesion保存在服务端，相对更加安全
3. 大小限制：Cookie有大小限制，并且浏览器对cookie个数也有限制；Session没有大小限制，理论上至于服务器的内存大小有关
4. 资源消耗：Seesion保存在服务器上存在一段时间才会消失，如果session过多会增加服务器的压力。

TCP粘包

什么是拆包粘包，为什么会出现？

• 粘包：一个数据包包含了发送端发送的两个数据包的信息

• TCP是基于字节流的，会把应用层的报文拆分为大小不等的数据块，TCP把这些数据块看作是一连串无边界的字节流

UDP没有粘包问题，但是有丢包和乱序。传送的数据单位是用户数据包，发送的时候既不会合并，也不会拆分。

解决办法

1. 特殊字符控制
2. 在包头首部添加数据包的长度