OSI与TCP/IP模型

image.png

应用层

应用层的任务是通过应用进程间的交互来完成特点网络应用。应用层协议定义的是应用进程间的通信和交互的规则。在互联网在的应用层协议有域名系统DNS、支持万维网应用的HTTP协议、支持电子邮件的SMTP协议。应用层交互的数据单元称为报文。

运输层

运输层负责为两台主机进程之间的通信提供通用的数据传输服务，应用进程利用该服务传送应用层报文。

运输层主要使用一下两种协议：

  1. 传输控制协议TCP：提供面向连接的，可靠的数据传输服务。
  2. 用户数据协议UDP：提供无连接的，尽最大努力的数据传输服务，不保证数据传输可靠性。

网络层

在通信 的两个计算之间可能经过多个数据链路和通信子网。网络层的任务就是选择合适的路由和交换节点，保证数据的及时传送。

数据链路层

网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的IP数据报分组封装成帧。

物理层

物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

TCP三次握手和四次挥手

为什么要三次握手

主要有两点原因

  1. 为了防止已失效的连接请求报文段突然又传送到了服务端，让服务器错误打开连接。若当前网络较为堵塞，客户端发送的请求如果在网络中滞留很久，并且客户端等待了一个超时重传后，重新请求连接。而之前滞留的请求最后到达了服务器，如果没有三次握手，服务器会建立两个连接。如果有三次握手，客户端会忽略服务器对滞留连接请求的确认，因此就不会再次打开连接。
  2. TCP的可靠性是需要sequence序列号来实现的，通信的双方都必须维护一个序列号，用来标识数据包的顺序，所以需要三次握手来约定确定双方的序列号起始值，并确认对方已经收到了序列号起始值。如果只是两次握手，只有连接发送方的起始序号能够被确认并保证可靠，而另一方的序列号得不到确认，不能保证可靠。

四次挥手

四次挥手的过程：

  1. 客户端发送连接释放报文，FIN = 1
  2. 服务端收到后发出确认，ACK = 1，确认的序号为收到的sequence序号加一
  3. 此时服务端进入close-wait状态，这个状态是为了让服务器端发送还未传送完毕的数据。
  4. 数据传送完后，服务器向客户端发送FIN连接释放报文，FIN设为1，ACK设为1（ack的确认序号和上一次确认序号一样。
  5. 客户端收到后发出确认，进入TIME-Wait状态，等待2MSL（最大报文存活时间）后释放链接。
  6. 服务端收到客户端的确认后，释放连接。

最后客户端还要等待2MSL的原因：

  1. 保证最后一个确认报文能够到达，如果服务端没有收到客户端发来的确认，那么会向客户端重新发送一次，而客户端就能在2MSL时间段内收到这个重传的报文，并重新发送确认回应。
  2. 是为了让本连接持续时间内产生的所有报文都从网络消失，这样使得下一个连接不会出现旧的连接请求报文。

    **

    TCP粘包/拆包

    一个数据包中包含了发送端发送的两个数据包的信息，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾，这种现象即为粘包。
    产生的原因：
    1.要发送的数据大于TCP剩余缓冲区的大小
    2.要发送的数据大于MSS最大报文长度
    3.TCP收到分组时，应用层不会立即读取，而是放在缓冲区，等到应用程序主动读取，当接受分组的速度 大于应用程序读取分组的速度时，多个包就会被存至缓存，应用程序读取时，就会读取多个首尾连接的包。
    如何处理TCP粘包和TCP拆包问题？
    无论是TCP拆包还是TCP粘包本质问题都在于无法区分包的界限，可以采用以下三种方式来区分包的界限
    1.消息数据固定长度，不足用0填充，但是浪费存储和网络资源
    2.使用分割符来区分包的界限
    3.数据包的头部中增加数据包长度字段

TCP与UDP的区别

  1. UDP在传输之前不需要建立连接，自然也不需要确认，传输方式不可靠。但效率高，所耗费的资源少。
  2. TCP提供可靠的连接服务，传送数据前必须建立连接，传送结束后要释放链接。TCP不提供广播或多播服务。由于TCP要提供可靠的，面向连接的传输服务，这会增加一些空间时间上的开销，比如报文的确认机制，流量控制，滑动窗口，计时器。这使得协议的首部较UDP大很多。

TCP协议如何保证可靠传输

  1. ARQ协议：当TCP发出一个段后，启动一个定时器，等待接收端发送确认报文段。如果不能及时收到一个确认，将重发这个报文段。
  2. TCP给发送的每一个包按序进行编号，接收方根据数据包顺序接收，整合再交给应用层。
  3. 校验和：TCP保持首部的数据校验和，目的是检测数据在传输过程中的任何变化，如果校验和不正确，接收端会丢弃这个报文段，并不发生确认收到此报文段。
  4. 在宏观上，在当前网络状况较为堵塞的情况下，TCP采用拥塞控制，减少控制数据的发送，以减少包的丢失。
  5. 在端到端上，采用TCP流量控制来控制发送方发送速率，保证接受方来得及接收。

ARQ协议

自动重传请求（Automatic repeat-request）。如果发送方在发送一段时间之内没有收到确认帧，它通常会重新发送。

停止等待ARQ协议

用来实现可靠传输，基本原理为每发完一个分组就停止发送，等待对方的ACK。如果超过一段时间后，说明没有发送成功，需要重新发送，知道收到确认后再发送下一个分组。若接收方收到重复就丢弃该分组，但需要发送确认。

优点为简单易于实现，缺点为信道利用率低，等待时间长。

连续ARQ协议

连续ARQ协议可提高信道利用率。发送方位置一个发送窗口，凡是位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组已经正确收到了。

TCP流量控制

流量控制是为了控制发送方的速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。

拥塞控制

  1. 目的：拥塞控制是为了防止过多的数据注入到网络，这样会使网络中的路由器或链路过载。拥塞控制是一个全局性的过程，宏观上降低网络负荷，减轻网络拥塞的情况。
  2. 拥塞控制的四种算法：
    • 慢开始：当主机开始发送数据时，如果立即把大量数据注入到网络，那么有可能会引起网路阻塞。所以比较好的方法是慢慢试探大小，也就是由小到大的增大拥塞窗口的值。初始值为1，当正确收到确认之后，将阻塞窗口cwnd加倍。
    • 拥塞避免：慢开始不可能按指数级无限增大，所以要设置慢开始的门限阈值ssthresh，当拥塞窗口的值大于等于ssthresh值时，每次确认只将窗口值加1。如果出现超时，就将ssthresh设置为拥塞窗口的一半，并重新执行慢开始。
    • 快重传：如果发送方收到3个重复的确认，则判断下一个报文段丢失，此时执行快重传，立即重传下一个报文段。此时只是单个报文段的丢失，而不是超时，因此执行快恢复。
    • 快恢复：快重传后执行快恢复，将ssthresh = cwnd/2，cwnd = ssthresh也就是将阈值设置为拥塞窗口的一半，并将拥塞窗口设置为阈值。

慢开始和快恢复的快慢是指cwnd的设定值而不是cwnd的增长速率。慢开始的初始值设置为1，快恢复的初始值设置为ssthresh阈值

在浏览器中输入url地址到显示主页的过程/Web 页面请求过程

1.ARP 解析 MAC 地址

  • 主机需要知道网站的域名对应的 IP 地址。向DNS服务器发送一个 DNS 查询报文，该报文指明 53 号端口，因为 DNS 服务器的端口号是 53。
  • 该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。
  • 该 IP 数据报被放入一个以太网帧中，该帧将发送到网关路由器。
  • DHCP 过程只知道网关路由器的 IP 地址，为了获取网关路由器的 MAC 地址，需要使用 ARP 协议。
  • 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该 ARP 查询报文放入一个具有广播目的地址（FF:FF:FF:FF:FF:FF）的以太网帧中，并向交换机发送该以太网帧，交换机将该帧转发给所有的连接设备，包括网关路由器。
  • 网关路由器接收到该帧后，不断向上分解得到 ARP 报文，发现其中的 IP 地址与其接口的 IP 地址匹配，因此就发送一个 ARP 回答报文，包含了它的 MAC 地址，发回给主机。

2. DNS 解析域名

  • 知道了网关路由器的 MAC 地址之后，就可以继续 DNS 的解析过程了。
  • 网关路由器接收到包含 DNS 查询报文的以太网帧后，抽取出 IP 数据报，并根据转发表决定该 IP 数据报应该转发的路由器。
  • 因为路由器具有内部网关协议（RIP、OSPF）和外部网关协议（BGP）这两种路由选择协议，因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。
  • 到达 DNS 服务器之后，DNS 服务器抽取出 DNS 查询报文，并在 DNS 数据库中查找待解析的域名。
  • 找到 DNS 记录之后，发送 DNS 回答报文，将该回答报文放入 UDP 报文段中，然后放入 IP 数据报中，通过路由器反向转发回网关路由器，并经过以太网交换机到达主机。

3. HTTP 请求页面

  • 有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
  • 在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
  • HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
  • 连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
  • HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
  • 浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。

HTTP的方法

安全方法

所谓安全是指，使用该方法不会在服务器上产生什么结果。GET方法和HEAD方法被认为是安全的。

GET方法

用于获取资源，在网络请求中绝大部分使用的是GET方法

HEAD方法

和GET方法类似，但是服务器在响应时只返回首部，不返回主体(body)。这就方便对资源的首部检查。还可以：

  • 在不获取资源的情况下了解资源的情况，比如通过MIME判断类型
  • 通过查看响应中的状态码，查看某个对象是否存在
  • 通过查看首部，测试资源是否被修改了。

PUT方法

让服务器用请求的主体部分来创建一个由请求的URL命名的新文档，或者那个URL已经存在，则用这个主体来替代它。

POST方法

POST主要用来传输数据，GET主要用来获取资源。

TRACE方法

当客户端发送一个请求时，在到达服务端的时候可能经过了多次修改，使用TRACE方法服务器会返回达到服务端时的请求报文。故TRACE用来查看代理和其他应用程序对用户请求所产生的效果。

TRACE请求中不能带有主体。TRACE的响应的主体包含了服务器收到的请求的精确副本。

OPTIONS方法

该方法请求服务器告知其支持的各种功能，可以询问服务器支持哪些方法

会返回Allow:GET,POST,HEAD,OPTIONS这样的内容

DELETE方法

请求服务器删除请求URL所指定的资源，但服务器并不保证会执行。

状态码

状态码 类别 含义
1XX Informational(信息性状态码) 接收的请求正在处理
2XX Success(成功状态码) 请求正常处理完毕
3XX Redirection(重定向状态码) 需要进行附加操作以完成请求
4XX Client Error(客户端错误状态码) 服务器无法处理请求
5XX Server Error（服务器错误状态码） 服务器处理出错

  1. 信息状态码

    1. 100 Continue：说明服务器收到了请求的初始部分，请客户端继续，客户端收到100 Continue的前提是它发送了100 Continue的Expect请求头部。当客户端愿意在发送实体之前等待100 continue的响应，那他就要发送一个携带了值为100 Continue的Expect的请求头部。
    2. 101 Switching Protocols 服务器正在根据客户端的指定，切换协议

  2. 成功状态码

    1. OK
    2. Created：用于已创建服务器对象的响应。响应主体部分应该包含各种引用了已创建资源的URL。
    3. Accepted：请求已被接受，但是服务器还未对其执行任何动作
    4. Non-Authoritative Information：实体首部的信息不是来自于源端服务器，而是来自资源的一份副本。

  3. 重定向状态码：


    告知客户端使用替代的位置来访问资源。通常使用一个重定向状态码和一个可选的Location首部来告知客户端资源已经被移走。
    1. 300 Multiple Choices ：客户端请求一个指向多个资源的URL时会返回这个状态码，比如某个HTML有英语和中文版本，返回该状态码时会带有一个选项列表。
    2. 301 Moved Permanently 在请求的URL已被移除时使用。响应的Location首部应该包含资源现在所处的URL
    3. 302 Found 和301类似，但是客户端使用响应Location首部来临时定位。将来仍然使用老的URL
    4. 303 See Other：告诉客户端应使用另一个URL来获取资源
    5. 304 NOT Modified：客户端可以通过所包含的请求首部，使其请求变成有条件的。
    6. 305 Use Proxy：说明必须通过一个代理来访问资源
    7. 306 （未使用）
    8. 307 Temporary Redirect：与301类似，但是客户端使用响应Location首部来临时定位。将来仍然使用老的URL

  4. 客户端错误状态码

    1. 400 Bad Request ：告知客户端发送了一个错误的请求
    2. 401 Unauthorized ：告知客户端在访问资源之前，先对自己进行认证
    3. 402 （未使用）保留
    4. 403 Forbidden：请求被服务器拒绝，可选在主体部分说明原因
    5. 404 NOT Found
    6. 405 Method NOT Allowed ：表示发起请求中带有请求的URL不支持的方法，应在该响应中包含Allow首部，以告知客户端对所请求的资源可以使用哪些方法
    7. 406 NOT Acceptable ： 客户端可以通过首部Accepted来指定愿意接受什么类型的实体，但当服务器没有与客户端可接受的URL想匹配的资源时，使用该响应码。
  5. 服务器错误状态码：
    1. 500 Internal Server Error ：服务器遇到一个妨碍它为请求服务器的错误时
    2. 501 NOTImplemented ：客户端发起的请求超出服务器的能力范围时
    3. 502 Bad Gateway：作为代理或网关使用的服务器在响应链的链路上收到了一条伪响应。
    4. 503 Service Unavailable ：说明服务器现在无法为请求提供服务，但将来可以
    5. 504 Gateway Timeout：来自一个网关或代理，他们在等待时进行响应时超时了
    6. 505 HTTP Version NOT Supported：服务器收到了他无法或不愿意支持的版本协议

短连接与长连接

  1. 短连接：为客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。这意味着每次都要新建一个TCP连接，开销会很大。
  2. 长连接：在使用长连接的情况下，当一个网页打开完成之后，客户端和服务器之间用于传输的TCP连接不会关闭，客户端会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
  • HTTP/1.1之前默认为短连接，如果需要使用长连接则使用Connection：Keep-Alive
  • HTTP/1.1开始默认是长连接，如果要断开连接，需要由客户端或者服务器端提出断开，使用Connection：close

HTTP1.0和HTTP1.1主要的区别

  1. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
  2. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  3. 新增缓存处理指令max-age：
    • max-age指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
    • max-age指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

在HTTP/1.1中，会优先处理max-age指令；
在HTTP/1.0中，max-age指令会被忽略掉。

  1. 支持分块传输编码：可以把数据分割成多块，让浏览器逐步显示页面。

Cookie

  1. Cookie介绍：
    HTTP请求是独立无状态的，在一个连接多个HTTP请求的情况下如果第一个请求出错了，后面的请求一般也能够继续处理，这样是为了让HTTP尽可能简单。
    HTTP1.1引入Cookie来保存状态信息，Cookie是服务器发送到用户浏览器并保存在本地的小块数据，它会在浏览器向同一服务器再次发送请求时被携带上，用于告知服务端的一些用户信息。
  2. Cookie用途：
    • 会话状态管理（用户登录状态、购物车以及其他记录的信息
    • 个性化设置（用户自定义设置、主题
    • 浏览器行为跟踪（跟踪分析用户行为等
  3. 创建过程：
    • 服务器发送的响应报文包含Set-Cookie首部字段，客户端得到后会存在浏览器中。
    • 客户端之后对同一个服务器发送请求时，会从浏览器中取出Cookie并在请求首部发送给服务器。
  4. Cookie和Session的区别和选择
    • Cookie存储在客户端，而Session存储在服务器上，Session相对来说较为安全，如果非要将一些隐私数据存在Cookie中，可以先对Cookie进行加密，然后再服务器进行解密。
    • Cookie只能存储ASCLL字符串，而Session可以存储任何类型，因此在考虑数据复杂性时首选Session
    • 对于大型网站，如果所有用户信息都存储在Session中，那么开销是非常大的，因此不建议将所有的信息都存储到Session中。

URI和URL的区别

image.png

HTTPS

HTTPS介绍

HTTP存在一些安全问题：

  • 使用明文进行通信，内容可能会被窃听
  • 不验证通信方的身份，通信方的身份有可能遭遇伪装
  • 无法证明报文的完整性，报文有可能遭篡改。

HTTPS是让HTTP先与SSL通信，再由SSL和TCP通信，这样HTTPS具有了加密（放窃听）、认证（防伪装）、完整性保护（防篡改）

对称加密和非对称加密

  1. 对称加密：加密和解密使用同一个密钥，这样运算速度快，但对称加密安全的前提是将密钥安全的传输给对方
  2. 非对称加密：加密和解密使用不同的密钥，可以用来加密或者签名：
    加密：公钥加密，私钥解密。
    签名：私钥签名，公钥验证签名。

HTTPS加密和解密

HTTPS采用对称加密和非对称加密相结合。非对称加密用于传输对称密钥来保证传输过程的安全性，获得对称密钥后使用对称密钥来通信来保证效率。

  1. 浏览器发送HTTPS请求，服务器响应客户端并发送公钥。
  2. 浏览器用公钥对对称密钥进行加密，发送给服务器端。
  3. 服务器端使用私钥进行解密，获得对称密钥。
  4. 为了提升通信效率，双方使用对称密钥通信。

签名和验证签名

通过使用证书来对通信方进行认证签名，签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过。

一般是对信息做一个hash计算得到一个hash值 。在把信息发送出去时，把这个hash值通过私钥加密后做为一个签名和信息一起发出去。 接收方在收到信息后，会重新计算信息的hash值，并利用证书上的公钥对信息所附带的hash值进行解密，再将通过计算得到的hash与通过解密得到的hash进行对比，如果一致，就说明信息的内容没有被修改过。

完整性保护

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

HTTP也提供了MD5报文摘要功能，但不是安全的。例如报文内容篡改后，再重新计算MD5值，通信接收方无法意识到发生了篡改。

HTTPS的报文摘要之所以安全，是因为结合了加密和认证两个操作。这样篡改者无法得到明文，自然很难重新计算摘要。