计算机网络面试速刷！！！

计算机网络面试

一.计算机网络的体系架构

1.计算机网络体系结构图

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

五层体系结构

2.计算机网络体系结构各个层的作用

2.1 应用层

应用层(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 页面的方法。（百度百科）

2.2 运输层

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

运输层主要使用以下两种协议:

  1. 传输控制协议 TCP（Transmission Control Protocol）--提供面向连接的，可靠的数据传输服务。其数据传输的单位是报文段
  2. 用户数据协议 UDP（User Datagram Protocol）--提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。其数据传输的单位是用户数据报

TCP 与 UDP 的对比见问题三。

2.3 网络层

在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是通过路由选择协议，选择合适的网间路由和交换结点，分配合适的地址，确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

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

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

互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Internet Protocol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层。

2.4 数据链路层

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

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

2.5 物理层

在物理层上所传送的数据单位是比特。

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

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

二.TCP的三次握手和四次挥手

TCP三次握手

1.TCP的三次握手

主机A客户端，主机B服务端

  1. 主机A通过向主机B 发送一个含有同步序列号标志位的数据段（SYN）给主机B ，并指明主机A的初始化序列号，向主机B 请求建立连接，通过这个数据段，主机A告诉主机B 两件事：我想要和你通信；你可以用哪个序列号作为起始数据段来回应我。
  2. 主机B 收到主机A的请求后，用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A，并且也是指定了自己的初始化序列号 ，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用哪个序列号作为起始数据段来回应我。
  3. 主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B 的数据段：“我已收到回复,我现在要开始传输实际数据了”。

这样3次握手就完成了，主机A和主机B 就可以传输数据了

2.为什么需要三次握手

  • 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的，指定自己的初始化序列号为后面的可靠性传送做准备。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

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

  • 如果是用两次握手，则会出现下面这种情况：

    /*如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

3. 第2次握手传回了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。

而回传SYN则是为了建立并确认从服务端到客户端的通信。

4. 什么是半连接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题：
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

4.四次挥手的流程

TCP四次挥手

断开一个 TCP 连接则需要“四次挥手”：

收到一个FIN只意味着在这一方向上没有数据流动。

  • 客户端-发送一个 FIN（连接释放报文段），用来关闭客户端到服务器的数据传送，提出停止TCP连接的请求，此时客户端处于 FIN_WAIT1状态，等待服务端确认
  • 服务器-收到这个 FIN（连接释放报文段）后即发出ACK（确认报文段），此时服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。
    • 客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
  • 服务器-提出反方向的关闭请求，当服务端没有要向客户端发出的数据后，服务端发出连接释放报文段，关闭服务端到客户端的连接，发送一个FIN给客户端
    • 此时服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
  • 客户端-收到这个 FIN后对其作出相应，它发回一 个 ACK
    • 此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。（此时双方向的连接停止）

5.为什么要需要四次挥手

  • 任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。
    • 所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
  • 建立连接时：服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
  • 但是关闭连接时：当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
  • 当对方也没有数据再发送的时候，就也会发出连接释放通知，这一方确认后就完全关闭了TCP连接。

6. 了解2MSL等待状态吗？四次挥手释放连接时，等待2MSL的意义

  • TIME_WAIT状态也称作为2MSL等待状态。
  • MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
  • 保证客户端发送的最后一个ACK报文段能够到达服务端。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
  • 防止“已失效的连接请求报文段”出现在本连接中。客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

三.TCP和UDP

1.TCP和UDP的区别

TCP、UDP协议的区别

  • TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。（面向连接）并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端（保证数据的准确性和顺序）。（可靠）（一般用于文件传输、发送和接收邮件）

  • UDP（User Data Protocol，用户数据报协议）是一个无连接、简单的面向数据报的运输层协议。它知道IP和端口号就直接进行传输，不需要建立连接（无连接）。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。（可能会丢包，不保证数据的顺序和正确性）由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。（不可靠）（一般用于打电话、通信）

    它不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并。（面向数据报）

2.TCP 协议如何保证可靠传输

2.1分割

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

2.2排序

TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

2.3 校验和

TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

2.4 丢弃

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

2.5 滑动窗口和流量控制

  • TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
  • TCP 使用的流量控制协议是可变大小的滑动窗口协议。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小（发送方的发送窗口不能超过接收方给出的接收串口），从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

2.6 拥塞控制

  • 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。

  • 拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。

  • 相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

  • 为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

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

    • 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。（慢开始的慢，不是指cwnd增长的慢，而是TCP开始发送报文时先设置cwnd=1）
    • 拥塞避免： 为了防止拥塞窗口cwnd增长过大引起网络阻塞，还需要设置一个慢开始门限状态变量，拥塞避免算法的思路是：当cwnd>慢开始门限，则让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT（一个传播轮次）就把发送放的cwnd加1.
    • 快重传：可以让发送方尽早知道发生了个别报文段的丢失。快重传算法的思路是，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，从而立即进行快重传，防止出现超时，发送方误以为网络发生拥塞，从而让发送方错误地启动慢开始算法，降低传输效率
    • 快恢复：当发送方找到丢失的个别报文段，不启动慢开始算法，而是执行快恢复算法。它的思路是：将慢开始门限值ssthresh设为当前拥塞窗口的一半（ssthresh=cwnd/2）,同时将拥塞窗口也减少一半（cwnd=cwnd/2）,然后开始执行拥塞避免算法
      • 需要注意：当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

2.7 ARQ协议

  • 自动重传请求（Automatic Repeat-reQuest，ARQ），它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

  • 停止等待ARQ协议

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

    • 优点： 简单
    • 缺点： 信道利用率低，等待时间长

  • 连续ARQ协议

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

    • 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
    • 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

2.8超时重传

当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

  • 1）出现差错情况（超时重传）:
    • 停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。
      • 连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。
  • 2）确认丢失和确认迟到
    • 确认丢失 ：确认消息在传输过程丢失。当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。

四.在浏览器中输入url地址 ->> 显示主页的过程

  • 输入域名回车后，会先在浏览器缓存中进行查找，查找是否缓存过该网站域名所对应的ip地址，没有的话就检查本机中有没有该域名的映射。（都是在本机上完成的，如果查找不到，就要向远程DNS服务器发起解析域名的请求）

    • 如果本地DNS服务器的设置了转发器进行查询

      • DNS解析是一个递归查询的过程 ：首先主机在本地域名服务器中查询IP地址，如果没有找到的情况下，本地域名服务器就以DNS客户的身份，向其他根域名服务器发送一个查询请求，如果根域名服务器也不存在该域名时，本地域名服务器会向再上一级域名服务器发送一个查询请求，依次类推下去。直到最后本地域名服务器得到该域名的IP地址并把它缓存到本地，供下次查询使用。
      • 递归：客户端只发一次请求，要求对方给出最终结果。

    • 如果本地DNS服务器的未设置转发器进行查询

      • DNS解析是一个迭代查询的过程：本地域名服务器向根域名服务器进行查询，本地域名服务器会向根域名服务器发送一个迭代查询请求，当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”，然后让本地服务器再向顶级域名服务器查询直到知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。

      • 迭代：客户端发出一次请求，对方如果没有授权回答，它就会返回一个能解答这个查询的其它名称服务器列表，

        ​ 客户端会再向返回的列表中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果。

        除了参考javaguide，还有https://www.cnblogs.com/qingdaofu/p/7399670.html！

3.建立TCP连接

  • 客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。需要用到三报文握手

4.发送HTTP请求

  • 发送HTTP请求的过程就是构建HTTP请求报文，并通过TCP协议将HTTP请求报文分割成报文段，发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。
  • 当建立TCP连接的三报文握手的前两部分完成后（即完成一个RTT时间），万维网就会把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给服务器

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

  • 服务器通过TCP协议，接收客户端的分割的请求报文段，并按照原来的顺序重组HTTP请求报文，收到HTTP请求报文之后，就会把所请求的文档作为HTTP响应响应报文返回给客户，HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。

  • 后端从在固定的端口接收到TCP连接的HTTP请求报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用

    • Socket编程

      • Socket（套接字）是网络中的一个通信节点
      • 分为客户端Socket与服务器ServerSocket
      • 通信要求是：IP地址+端口号
      • 开发步骤

6.浏览器解析渲染页面

7.连接结束

五. HTTP报文结构

1. 请求报文

  • 请求行的组成：方法+请求资源的URL+HTTP的版本

  • 请求方法：就是对所请求对象的操作，请求报文的类型是由其所请求的方法决定的

    • HTTP/1.1协议中共定义了八种方法（有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式
      HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
      HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

  • 请求报文的举例

2. 响应报文

  • 状态行的组成：HTTP版本号+状态码+解释状态码的简单语句

    • 如：HTTP/1.1 202 Accepted
    • 如：HTTP/1.1 404 Bad Request

  • 响应报文的举例：

六.状态码

1.常见的状态码分类

  • 400：错误的请求

  • 405：请求的方法不允许（post/get等）

  • 502：网关错误

  • HTTP/1.1 301 Moved Permanently

  • Location: http://www.xyz/index.html

    400请求出现问题，500后端服务端代码出现问题

2.请求转发（forward）和重定向（redirect）

  • 相同点：页面都会实现跳转

  • 不同点：请求转发的时候，url不会发生改变；重定向的时候，url地址栏会发生变化

  • 一个web资源（B）收到客户端（A）的请求后，B通知客户端A去访问另外一个Web资源（C），这个过程叫重定向

七. HTTP协议

1.长连接,短连接

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

HTTP/1.0

  • 默认使用短连接。
  • 也就是说，客户端和服务器每进行一次HTTP数据传输操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

HTTP/1.1

  • 默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接，从而可以获得多个web资源。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

2.HTTP1.0/1.1的区别

  • 长连接 :

    • 在HTTP1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。
    • HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

  • 线头/队头阻塞：

    • 在HTTP1.0中，需要等待svr响应才可以发送请求。

    • 在HTTP1.1中，利用 Pipeling，则不需要等待svr响应就可以发送请求，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

3.HTTP2.0和HTTP1.X相比的新特性

  • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。HTTP2.0的协议解析采用二进制格式，每个请求、响应以数据流的形式传输，实现方便且健壮。

  • 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

    • HTTP2.0的多路复用可以解决 请求/响应级别的 线头/队头阻塞？

    • HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

  • header压缩，HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache（缓存）一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

    • 当需要传输的header在表中存在，就传送该索引过去。

4.HTTP协议的特点

  • 无连接：虽然HTTP协议使用了面向连接的TCP作为传输层协议，保证了数据的可靠传输，但是HTTP协议本身是无连接的，也就是说HTTP使用了TCP连接，但在通信双方交换HTTP报文之前是不需要建立HTTP连接。

  • 无状态：HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。

    • 也就是说：当同一个客户第二次访问同一个服务器的时候，服务器的响应与第一次访问时是相同的，服务器不记得这个客户访问过，也不记得该客户做过的操作等等。

    • 那么我们保存用户状态呢？？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。

4.1 如何保存用户状态？

Session机制

  • Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。具体步骤如下：
  • 当客户端浏览器向服务端（网站）发送请求时，服务器会首先进行判断，首先检查这个客户端的请求里是否已包含了一个session标识（称为session id）
    • 如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用
    • 如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，一个Session独占一个客户的浏览器，session id的值是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。客户端可以通过SessionId获取到Session中的数据。大部分情况下，我们的SessionID是存放在Cookie中，用来进行用户跟踪。

Cookie机制

  • Cookie存放在客户端（通常为浏览器），由服务端生成的。工作原理如下：

    • 当用户（客户端浏览器）第一次浏览某个使用Cookie的网站（服务端）时，该网站的服务器就进行如下工作：

      • 1、服务器创建一个Cookie对象

        默认情况下它是一个会话级别的cookie，存储在浏览器的内存中，用户退出浏览器之后被删除。如果网站希望浏览器将该Cookie存储在磁盘上，则需要设置最大时效（maxAge），并给出一个以秒为单位的时间（将最大时效设为0则是命令浏览器删除该Cookie）；

        将Cookie放入到HTTP响应报头，将Cookie插入到一个 Set-Cookie HTTP请求报头中。

        服务端发送该HTTP响应报文给客户端浏览器。

        2、设置存储Cookie

        客户端浏览器收到该响应报文之后，根据报文头里的Set-Cookied特殊的指示，生成相应的Cookie，保存在客户端。该Cookie里面记录着用户当前的信息。

        (1、2总结：服务器创建一个Cookie对象，服务器把客户的数据写到Cookie中，然后发送到客户的浏览器上，浏览器保存)

        3、发送Cookie

        当用户再次访问该网站时，浏览器首先检查所有存储的Cookies，如果某个存在该网站的Cookie，则把该cookie附在请求资源的HTTP请求头上发送给服务器。

        4、读取Cookie

        服务器接收到用户的HTTP请求报文之后，从报文头获取到该用户的Cookie，服务器端通过Cookie中携带的数据区分不同的用户，从里面找到所需要的东西。

4.2 如果客户端的浏览器禁用了cookie，要怎么进行用户数据的跟踪？

  • 经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。

    • 可以在URL后面手动拼接jsessionid

    • 也可以**使用响应对象HttpServletRequest中的encodeURL(String path)方法实现jsessionid的自动拼接 **

      String url = resp.encodeURL("/session/list");

  • 还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

    <form name=”"testform”" action=”"/xxx”"> 
     <input type=”"hidden”" name=”"jsessionid”" value=”"ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764″”/>
     <input type=”"text”"> 
    </form>

4.3 Cookie和Session的区别

1.从存储位置上来看：Cookie：服务器创建一个Cookie对象，服务器把客户的数据写到Cookie中，然后发送到客户的浏览器上，浏览器保存

Session：服务器会给每一个用户（浏览器）创建一个Session对象（包含SessionID），服务器把用户的数据写到用户独有的Session上，服务器保存（一个Session独占一个客户的浏览器），客户端可以通过SessionId获取到Session中的数据。大部分情况下，我们的SessionID是存放在Cookie中，用来进行用户跟踪跟踪。

2.从安全方面：Cooike不是很安全，HTTP请求中的Cookie是明文传递的，别人可以分析客户存放在本地的Cooike并进行cooike欺骗，考虑到安全应当使用session，Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险，一般将登陆信息等重要信息（如：保存购物车信息，网站上面经常用到的数据）存放在Session，其他信息如果需要保留可以存在Cooike中。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密（HTTPS）。

3.从对服务器的影响上来看：Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。而Cookie保管在客户端，不占用服务器资源。假如并发阅读的用户十分多，Cookie是很好的选择。

4.从存储空间来看：单个Cooike保存的数据不能超过4k，对于复杂的存储需求来说是不够的，很多浏览器都限制一个站点最多保存20个cooike
原文链接：https://blog.csdn.net/qq_43628350/article/details/84748107和https://www.cnblogs.com/nieliangcai/p/8864791.html

直接关闭浏览器就可以注销cookie和session

5.HTTPS协议

  • HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

    HTTPS

  • HTTPS过程：HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，

    这个握手阶段分成五步。

第一步，爱丽丝给出SSL/TLS协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法（对称？非对称？hash？）。

第二步，鲍勃确认使用的加密通信协议版本 以及 双方使用的加密方法，并给出数字证书（保证了服务器在将非对称加密算法的公钥传给浏览器时的安全性(不会被中间人篡改)，同时也标志了服务器的身份，确保服务端不是别人冒充的）、以及一个服务器生成的随机数（Server random）。

第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。

第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。

第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

  • 为什么使用三个随机数生成对话密钥：不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
  • 注意：握手之后的对话使用"对话密钥"加密（对称加密）

选自：http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html 和https://www.cnblogs.com/digdeep/p/4832885.html

6.HTTP和HTTPS的区别

  • 端口：

    • HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

  • 安全性和资源消耗：

    • HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。

    • 所有传输的内容都经过加密，利用对称加密算法来加密网页内容，并使用非对称加密算法（利用服务器证书的公钥加密，服务器的私钥解密）来获得对称加密算法的秘钥，从而保证了对称加密算法的秘钥的安全，也就保证了对称加密算法的安全。

    所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

    • 1）对称加密算法：就是加密和解密使用同一个密钥的加密算法。因为加密方和解密方使用的密钥相同，所以称为称为对称加密，也称为单钥加密方法。

      优点是：加密和解密运算速度快，所以对称加密算法通常在消息发送方需要加密大量数据时使用；

      缺点是：安全性差，如果一方的密钥遭泄露，那么整个通信就会被破解。另外加密之前双方需要同步密钥;

      常用对称加密算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等;

      2）非对称加密算法：而非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥(public key，简称公钥)和私有密钥(private key，简称私钥)。

      公钥和私钥是一对：公钥用来加密，私钥解密，而且公钥是公开的，私钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。

      有点是：安全性更好，私钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。

      缺点是：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

八. URI和URL的区别

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

九. IPv4和IPv6的区别

posted @ 2021-05-05 13:12  维他命D片  阅读(126)  评论(0)  编辑  收藏  举报