计算机网络

OSI与TCP/IP各层的结构与功能,都有哪些协议?

学习计算机⽹络时我们⼀般采⽤折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采⽤⼀种只有五层协议的体系结构，这样既简洁⼜能将概念阐述清楚。

image-20210504212236543

结合互联⽹的情况，⾃上⽽下地，⾮常简要的介绍⼀下各层的作⽤。

应⽤层

应⽤层(application-layer）的任务是通过应⽤进程间的交互来完成特定⽹络应⽤。应⽤层协议定义的 是应⽤进程（进程：主机中正在运⾏的程序）间的通信和交互的规则。对于不同的⽹络应⽤需要不同的 应⽤层协议。在互联⽹中应⽤层协议很多，如域名系统DNS，⽀持万维⽹应⽤的 HTTP协议，⽀持电⼦邮件的 SMTP协议等等。我们把应⽤层交互的数据单元称为报⽂。

域名系统

域名系统(Domain Name System缩写 DNS，Domain Name被译为域名)是因特⽹的⼀项核⼼服务，它作为可以将域名和IP地址相互映射的⼀个分布式数据库，能够使⼈更⽅便的访问互联⽹，⽽不⽤去记住能够被机器直接读取的IP数串。（百度百科）例如：⼀个公司的 Web ⽹站可看作是它在⽹上的⻔户，⽽域名就相当于其⻔牌地址，通常域名都使⽤该公司的名称或简称。例如上⾯提到的微软公司 的域名，类似的还有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等

HTTP协议

超⽂本传输协议（HTTP，HyperText Transfer Protocol)是互联⽹上应⽤最为⼴泛的⼀种⽹络协议。所有的 WWW（万维⽹） ⽂件都必须遵守这个标准。设计 HTTP 最初的⽬的是为了提供⼀种发布和接收 HTML ⻚⾯的⽅法。（百度百科）

运输层

运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通⽤的数据传输服务。应⽤进程利⽤该服务传送应⽤层报⽂。“通⽤的”是指并不针对某⼀个特定的⽹络应⽤，⽽是多种应⽤可 以使⽤同⼀个运输层服务。由于⼀台主机可同时运⾏多个线程，因此运输层有复⽤和分⽤的功能。所谓 复⽤就是指多个应⽤层进程可同时使⽤下⾯运输层的服务，分⽤和复⽤相反，是运输层把收到的信息分 别交付上⾯应⽤层中的相应进程。

运输层主要使⽤以下两种协议:
  1. 传输控制协议 TCP（Transmission Control Protocol）--提供⾯向连接的，可靠的数据传输服务。
  2. ⽤户数据协议 UDP（User Datagram Protocol）--提供⽆连接的，尽最⼤努⼒的数据传输服务（不保证数据传输的可靠性）。

TCP 与 UDP 的对⽐⻅问题三。

⽹络层

在 计算机⽹络中进⾏通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信⼦

⽹。⽹络层的任务就是选择合适的⽹间路由和交换结点， 确保数据及时传送。 在发送数据时，⽹络层把运输层产⽣的报⽂段或⽤户数据报封装成分组和包进⾏传送。在 TCP/IP 体系结构中，由于⽹络层使

⽤ IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

这⾥要注意：不要把运输层的“⽤户数据报 UDP ”和⽹络层的“ IP 数据报”弄混。另外，⽆论是哪⼀层的数据单元，都可笼统地⽤“分组”来表示。

这⾥强调指出，⽹络层中的“⽹络”⼆字已经不是我们通常谈到的具体⽹络，⽽是指计算机⽹络体系结构 模型中第三层的名称.

互联⽹是由⼤量的异构（heterogeneous）⽹络通过路由器（router）相互连接起来的。互联⽹使⽤的

⽹络层协议是⽆连接的⽹际协议（Intert Protocol）和许多路由选择协议，因此互联⽹的⽹络层也叫做⽹际层或IP层。

数据链路层

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在⼀段⼀段的链路上传送的，这就需要使⽤专⻔的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将⽹络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每⼀帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道⼀个帧从哪个⽐特开始和到哪个⽐特结束。这样，数据链路 层在收到⼀个帧后，就可从中提出数据部分，上交给⽹络层。 控制信息还使接收端能够检测到所收到的帧中有误差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在⽹络中传 送下去⽩⽩浪费⽹络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要 检错，⽽且还要纠错），那么就要采⽤可靠性传输协议来纠正出现的差错。这种⽅法会使链路层的协议 复杂些。

物理层

在物理层上所传送的数据单位是⽐特。 物理层(physical layer)的作⽤是实现相邻计算机节点之间⽐特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上⾯的数据链路层不必考虑⽹络的具体传输介质是什么。“透明传送⽐特流”表示经实际电路传送后的⽐特流没有发⽣变化，对传送的⽐特流来说，这个电路好像是看不⻅的。

在互联⽹使⽤的各种协中最重要和最著名的就是 TCP/IP 两个协议。现在⼈们经常提到的TCP/IP并不⼀定单指TCP和IP这两个具体的协议，⽽往往表示互联⽹所使⽤的整个TCP/IP协议族。

总结⼀下

image-20210504212402309

TCP 三次握⼿和四次挥⼿(⾯试常客)

为了准确⽆误地把数据送达⽬标处，TCP协议采⽤了三次握⼿策略。

TCP 三次握⼿漫画图解

如下图所示，下⾯的两个机器⼈通过3次握⼿确定了对⽅能正确接收和发送消息(图⽚来源：《图解HTTP》)。

image-20210504212428712

简单示意图：

image-20210504212511960

  • 客户端–发送带有 SYN 标志的数据包–⼀次握⼿–服务端
  • 服务端–发送带有 SYN/ACK 标志的数据包–⼆次握⼿–客户端
  • 客户端–发送带有带有 ACK 标志的数据包–三次握⼿–服务端

为什么要三次握⼿

三次握⼿的⽬的是建⽴可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，⽽三次握⼿最主 要的⽬的就是双⽅确认⾃⼰与对⽅的发送与接收是正常的。

第⼀次握⼿：Client 什么都不能确认；Server 确认了对⽅发送正常，⾃⼰接收正常

第⼆次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：对⽅发送正常，⾃⼰接收正常

第三次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常

所以三次握⼿就能确认双发收发功能都正常，缺⼀不可。

为什么要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

SYN 是 TCP/IP 建⽴连接时使⽤的握⼿信号。在客户机和服务器之间建⽴正常的 TCP ⽹络连接时， 客户机⾸先发出⼀个 SYN 消息，服务器使⽤ SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的⼀种传输控制字符。它表示确认发来的数据已经接受⽆误。 ]）消息响应。这样在客户机和服务器之间才能建⽴起可靠的TCP连接，数据才可以在客户机和服务器之间传递

传了 SYN,为啥还要传 ACK

双⽅通信⽆误必须是两者互相发送信息都⽆误。传了 SYN，证明发送⽅到接收⽅的通道没有问题，但是接收⽅到发送⽅的通道还需要 ACK 信号来进⾏验证。

image-20210504212634523

断开⼀个 TCP 连接则需要“四次挥⼿”：

  • 客户端-发送⼀个 FIN，⽤来关闭客户端到服务器的数据传送
  • 服务器-收到这个 FIN，它发回⼀ 个 ACK，确认序号为收到的序号加1 。和 SYN ⼀样，⼀个
  • FIN 将占⽤⼀个序号
  • 服务器-关闭与客户端的连接，发送⼀个FIN给客户端
  • 客户端-发回 ACK 报⽂确认，并将确认序号设置为收到序号加1

为什么要四次挥⼿

任何⼀⽅都可以在数据传送结束后发出连接释放的通知，待对⽅确认后进⼊半关闭状态。当另⼀⽅也没 有数据再发送的时候，则发出连接释放通知，对⽅确认后就完全关闭了TCP连接。

举个例⼦：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着⾃⼰的节奏结束通话，于是 B 可能⼜巴拉巴拉说了⼀通，最后B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

TCP,UDP 协议的区别

image-20210504212750625

UDP 在传送数据之前不需要先建⽴连接，远地主机在收到 UDP 报⽂后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下 UDP 确是⼀种最有效的⼯作⽅式（⼀般⽤于即时通信），⽐如： QQ 语⾳、 QQ 视频 、直播等等

TCP 提供⾯向连接的服务。在传送数据之前必须先建⽴连接，数据传送结束后要释放连接。 TCP 不提供⼴播或多播服务。由于 TCP 要提供可靠的，⾯向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握⼿来建⽴连接，⽽且在数据传递时，有确认、窗⼝、重传、拥塞控制机制，在数据传 完后，还会断开连接⽤来节约系统资源），这⼀难以避免增加了许多开销，如确认，流量控制，计时器 以及连接管理等。这不仅使协议数据单元的⾸部增⼤很多，还要占⽤许多处理机资源。TCP ⼀般⽤于⽂件传输、发送和接收邮件、远程登录等场景。

TCP 协议如何保证可靠传输

  1. 应⽤数据被分割成 TCP 认为最适合发送的数据块。

  2. TCP 给发送的每⼀个包进⾏编号，接收⽅对数据包进⾏排序，把有序数据传送给应⽤层。

  3. 校验和： TCP 将保持它⾸部和数据的检验和。这是⼀个端到端的检验和，⽬的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报⽂段和不确认收到此报⽂段。

  4. TCP 的接收端会丢弃重复的数据。

  5. 流量控制： TCP 连接的每⼀⽅都有固定⼤⼩的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收⽅来不及处理发送⽅的数据，能提示发送⽅降低发送的速率，防⽌ 包丢失。TCP 使⽤的流量控制协议是可变⼤⼩的滑动窗⼝协议。 （TCP 利⽤滑动窗⼝实现流量控制）

  6. 拥塞控制： 当⽹络拥塞时，减少数据的发送。

  7. ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完⼀个分组就停⽌发送，等待对⽅确认。在收到确认后再发下⼀个分组。

  8. 超时重传： 当 TCP 发出⼀个段后，它启动⼀个定时器，等待⽬的端确认收到这个报⽂段。如果不能及时收到⼀个确认，将重发这个报⽂段。

ARQ协议

⾃动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之

⼀。它通过使⽤确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送⽅在发 送后⼀段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停⽌等待ARQ协议和连续ARQ协议。

停⽌等待ARQ协议

  • 停⽌等待协议是为了实现可靠传输的，它的基本原理就是每发完⼀个分组就停⽌发送，等待对⽅ 确认（回复ACK）。如果过了⼀段时间（超时时间后)，还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下⼀个分组；
  • 在停⽌等待协议中，若接收⽅收到重复分组，就丢弃该分组，但同时还要发送确认；

优点： 简单

缺点： 信道利⽤率低，等待时间⻓

1) ⽆差错情况:

发送⽅发送分组,接收⽅在规定时间内收到,并且回复确认.发送⽅再次发送。

2) 出现差错情况（超时重传）:

停⽌等待协议中超时重传是指只要超过⼀段时间仍然没有收到确认，就重传前⾯发送过的分组（认为刚 才发送过的分组丢失了）。因此每发送完⼀个分组需要设置⼀个超时计时器，其重传时间应⽐数据在分 组传输的平均往返时间更⻓⼀些。这种⾃动重传⽅式常称为 ⾃动重传请求 ARQ 。另外在停⽌等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提⾼信道利⽤率。发送维持⼀个发送窗⼝，凡位于发送窗⼝内的分组可连续发送出去，⽽不需要等待对⽅确认。接收⽅⼀般采⽤ 累积确认，对按序到达的最后⼀个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到
  • 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了⼀个M1确认消息，但却在传输过程中丢失。⽽A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息 后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失)。
  • 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1)。此时A收到了B 第⼆次发送的确认消息。接着发送其他数据。过了⼀会，A收到了B第⼀次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

连续ARQ协议

连续 ARQ 协议可提⾼信道利⽤率。发送⽅维持⼀个发送窗⼝，凡位于发送窗⼝内的分组可以连续发送出去，⽽不需要等待对⽅确认。接收⽅⼀般采⽤累计确认，对按序到达的最后⼀个分组发送确认，表明 到这个分组为⽌的所有分组都已经正确收到了。

优点： 信道利⽤率⾼，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送⽅反映出接收⽅已经正确收到的所有分组的信息。 ⽐如：发送⽅发送了 5条 消 息，中间第三条丢失（3号），这时接收⽅只能对前两个发送确认。发送⽅⽆法知道后三个分组的下 落，⽽只好把后三个全部重传⼀次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的N 个消息。

滑动窗⼝和流量控制

TCP 利⽤滑动窗⼝实现流量控制。流量控制是为了控制发送⽅发送速率，保证接收⽅来得及接收。 接收⽅发送的确认报⽂中的窗⼝字段可以⽤来控制发送⽅窗⼝⼤⼩，从⽽影响发送⽅的发送速率。将窗⼝ 字段设置为 0，则发送⽅不能发送数据。

拥塞控制

在某段时间，若对⽹络中某⼀资源的需求超过了该资源所能提供的可⽤部分，⽹络的性能就要变坏。这 种情况就叫拥塞。拥塞控制就是为了防⽌过多的数据注⼊到⽹络中，这样就可以使⽹络中的路由器或链 路不致过载。拥塞控制所要做的都有⼀个前提，就是⽹络能够承受现有的⽹络负荷。拥塞控制是⼀个全 局性的过程，涉及到所有的主机，所有的路由器，以及与降低⽹络传输性能有关的所有因素。相反，流 量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据 的速率，以便使接收端来得及接收。

为了进⾏拥塞控制，TCP 发送⽅要维持⼀个 拥塞窗⼝(cwnd) 的状态变量。拥塞控制窗⼝的⼤⼩取决于⽹络的拥塞程度，并且动态变化。发送⽅让⾃⼰的发送窗⼝取为拥塞窗⼝和接收⽅的接受窗⼝中较⼩的⼀个。

TCP的拥塞控制采⽤了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在⽹络层也可以使路由器采⽤适当的分组丢弃策略（如主动队列管理 AQM），以减少⽹络拥塞的发⽣。

  • 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果⽴即把⼤量数据字节注⼊到⽹络， 那么可能会引起⽹络阻塞，因为现在还不知道⽹络的符合情况。经验表明，较好的⽅法是先探测⼀下，即由⼩到⼤逐渐增⼤发送窗⼝，也就是由⼩到⼤逐渐增⼤拥塞窗⼝数值。cwnd初始值为1，每经过⼀个传播轮次，cwnd加倍。
  • 拥塞避免： 拥塞避免算法的思路是让拥塞窗⼝cwnd缓慢增⼤，即每经过⼀个往返时间RTT就把发送放的cwnd加1.
  • 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR)是⼀种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使⽤定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到⼀个不按顺序的数据段，它会⽴即给发送机发送⼀个重复确认。如果发送机接收 到三个重复确认，它会假定确认件指出的数据段丢失了，并⽴即重传这些丢失的数据段。有了FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地⼯作。当有多个数据信息包在某⼀段很短的时间内丢失时，它则不能很有效 地⼯作。

在浏览器中输⼊url地址 ->> 显示主⻚的过程

image-20210504212926439

总体来说分为以下⼏个过程:

  1. DNS解析

  2. TCP连接

  3. 发送HTTP请求

  4. 服务器处理请求并返回HTTP报⽂

  5. 浏览器解析渲染⻚⾯

  6. 连接结束

状态码

image-20210504212951409

各种协议与HTTP协议之间的关系

image-20210504213018339

HTTP⻓连接,短连接

在HTTP/1.0中默认使⽤短连接。也就是说，客户端和服务器每进⾏⼀次HTTP操作，就建⽴⼀次连接，任 务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web⻚中包含有其他的Web资源（如JavaScript⽂件、图像⽂件、CSS⽂件等），每遇到这样⼀个Web资源，浏览器就会重新建⽴⼀个HTTP会话。

⽽从HTTP/起，默认使⽤⻓连接，⽤以保持连接特性。使⽤⻓连接的HTTP协议，会在响应头加⼊这⾏ 代码：

Connection:keep-alive

在使⽤⻓连接的情况下，当⼀个⽹⻚打开完成后，客户端和服务器之间⽤于传输HTTP数据的TCP连接不 会关闭，客户端再次访问这个服务器时，会继续使⽤这⼀条已经建⽴的连接。Keep-Alive不会永久保持连接，它有⼀个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现⻓连接需要客 户端和服务端都⽀持⻓连接。

HTTP协议的⻓连接和短连接，实质上是TCP协议的⻓连接和短连接。

HTTP是不保存状态的协议,如何保存⽤户状态?

HTTP 是⼀种不保存状态，即⽆状态（stateless）协议。也就是说 HTTP 协议⾃身不对请求和响应之间的通信状态进⾏保存。那么我们保存⽤户状态呢？Session 机制的存在就是为了解决这个问题， Session 的主要作⽤就是通过服务端记录⽤户的状态。典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个⽤户操作的，因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的Session 之后就可以标识这个⽤户并且跟踪这个⽤户了（⼀般情况下，服务器会在⼀定时间内保存这个Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的⽅法很多，最常⽤的就是内存和数据库(⽐如是使⽤内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？⼤部分情况下，我们都是通过在Cookie 中附加⼀个 Session ID 来⽅式来跟踪。

最常⽤的就是利⽤ URL 重写把 Session ID 直接附加在URL路径的后⾯。

image-20210504213126662

Cookie的作⽤是什么?和Session有什么区别？

Cookie 和 Session都是⽤来跟踪浏览器⽤户身份的会话⽅式，但是两者的应⽤场景不太⼀样。

Cookie ⼀般⽤来保存⽤户信息 ⽐如①我们在 Cookie 中保存已经登录过得⽤户信息，下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了；②⼀般的⽹站都会有保持登录也就是说下次你再访 问⽹站的时候就不需要重新登录了，这是因为⽤户登录的时候我们可以存放了⼀个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找⽤户即可(为了安全考虑，重新登录⼀般要将 Token 重写)；③登录⼀次⽹站后访问⽹站其他⻚⾯不需要重新登录。Session 的主要作⽤就是通过服务端记录⽤户的状态。 典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个⽤户操作的，因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，⽽Session存储在服务器上，相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息，不要直接写⼊ Cookie 中，最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。

HTTP 1.0和HTTP 的主要区别是什么?

HTTP1.0最早在⽹⻚中使⽤是在1996年，那个时候只是使⽤⼀些较为简单的⽹⻚上和⽹络请求上，⽽HTTP则在1999年才开始⼴泛应⽤于现在的各⼤浏览器⽹络请求中，同时HTTP也是当前使⽤最为⼴ 泛的HTTP协议。 主要区别主要体现在：

  1. ⻓连接 : 在HTTP/1.0中，默认使⽤的是短连接，也就是说每次请求都要重新建⽴⼀次连接。HTTP 是基于TCP/IP协议的,每⼀次建⽴或者断开连接都需要三次握⼿四次挥⼿的开销，如果每次请求都要这样的话，开销会⽐较⼤。因此最好能维持⼀个⻓连接，可以⽤个⻓连接来发多个请求。HTTP 起，默认使⽤⻓连接 ,默认开启Connection： keep-alive。 HTTP/的持续连接有⾮流⽔线⽅式和流⽔线⽅式 。流⽔线⽅式是客户在收到HTTP的响应报⽂之前就能接着发送新的请求报⽂。与之相对应的⾮流⽔线⽅式是客户在收到前⼀个响应后才能发送下⼀个请求。

  2. 错误状态响应码 :在HTTP中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发⽣冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

  3. 缓存处理 :在HTTP1.0中主要使⽤header⾥的If-Modified-Since,Expires来做为缓存判断的标准，HTTP则引⼊了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

  4. 带宽优化及⽹络连接的使⽤ :HTTP1.0中，存在⼀些浪费带宽的现象，例如客户端只是需要某个对象的⼀部分，⽽服务器却将整个对象送过来了，并且不⽀持断点续传功能，HTTP则在请求 头引⼊了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。

URI和URL的区别是什么?

  • URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源
  • URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，⽽且还指明了如何 locate 这个资源

URI的作⽤像身份证号⼀样，URL的作⽤更像家庭住址⼀样。URL是⼀种具体的URI，它不仅唯⼀标识资 源，⽽且还提供了定位该资源的信息。

HTTP 和 HTTPS 的区别？

  1. 端⼝ ：HTTP的URL由“http://”起始且默认使⽤端⼝80，⽽HTTPS的URL由“https://”起始且默认使⽤端⼝443。
  1. 安全性和资源消耗： HTTP协议运⾏在TCP之上，所有传输的内容都是明⽂，客户端和服务器端都

⽆法验证对⽅的身份。HTTPS是运⾏在SSL/TLS之上的HTTP协议，SSL/TLS 运⾏在TCP之上。所有传输的内容都经过加密，加密采⽤对称加密，但对称加密的密钥⽤服务器⽅的证书进⾏了⾮对称 加密。所以说，HTTP 安全性没有 HTTPS⾼，但是 HTTPS ⽐HTTP耗费更多服务器资源。

  • 对称加密：密钥只有⼀个，加密解密为同⼀个密码，且加解密速度快，典型的对称加密 算法有DES、AES等；
  • ⾮对称加密：密钥成对出现（且根据公钥⽆法推知私钥，根据私钥也⽆法推知公钥）， 加密解密使⽤不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密)，相对对称 加密速度较慢，典型的⾮对称加密算法有RSA、DSA等。

results matching ""

    No results matching ""