网络

【Java面试】计算机网络基础-OSI、TCP、HTTP、Soc

2020-06-13  本文已影响0人  隔壁王小猿

        小猿的某同事不甘于现状，近期到处投简历面试。某天，小猿只见某灰头土脸、唉声叹气，于是小猿本着看热闹不嫌事儿大的心态，一脸坏笑凑上去问：“大佬，最近面试咋样，是不是都拿好几个offer了~^_^”，某答道：“什么呀，面个试咋就这么难，一道面试题硬是让面试官扯出了整个计算机网络知识图谱，也是没谁了~”，小猿好奇问：“啥题，啥题~”，某答：“烂大街的一道题，面试前也准备了，唉，你说为啥面试官就能从这道题目扯出一堆题目...”(此处省略一万字)

        接下来小猿就给大家说说某遇到的这道题，还有它牵扯出的整个计算机网络的知识图谱。废话不多说，直接上题目

        题目描述一：请说说HTTP请求的整个过程

        题目描述二：当你在浏览器中输出某个URL，按下回车后都经历了什么样的流程

        题目描述三：请简单介绍一下HTTP是怎么工作的

        相信各位猿对这道题应该并不陌生，而且网上一搜一堆的讲解与答案，但是某遇到的这个大牛面试官，却可以从某的回答中延伸出更多的问题，如果想要过关，还是要对整个计算机网络的知识体系有比较深刻的理解才行。下面先贴出小猿对这个题目的理解和可能从这道题目引出的计算机网络的知识点，然后小猿对这些知识点慢慢的给大家分析。

小猿对题 目的理解：

  1. DNS解析：如果URL中是网址，需要向对这个网址进行域名解析，得到相应的IP地址，请求会逐层查询DNS缓存得到目的IP地址（DNS缓存由近到远依次是：浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存）

  2. TCP连接：根据IP地址和断开，找到对应的服务器，通过TCP的三次握手建立连接

  3. 发送HTTP请求：建立TCP连接后发起HTTP请求

  4. 服务器处理请求并返回HTTP报文：服务器根据请求参数得到返回结果，并返回HTTP报文

  5. 浏览器解析渲染页面：浏览器得到报文，解析HTML代码，并请求HTML代码中的资源（例如js、css等），然后渲染页面

  6. 连接结束：TCP4次挥手，HTTP断开连接

知识图谱

OSI七层架构

七层结构简介：

7层结构数据传输流程：

详细介绍每层的功能和

  1. 是计算机用户，以及各种应用程序和网络之间的接口：

  2. 是用户与网络，以及应用程序与网络间的直接接口，使得用户能够与网络进行交互式联系。

  3. 实现各种服务：该层具有的各种应用程序可以完成和实现用户请求的各种服务。

  4. 该层还负责协调各个应用程序间的工作。

  5. 应用层为用户提供的服务和协议有：文件服务、目录服务、文件传输服务（FTP）、远程登录服务（Telnet）、电子邮件服务（E-mail）、打印服务、安全服务、网络管理服务、数据库服务等。

  1. 对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层。

  2. 主要功能：数据格式处理、编码、压缩解压、加密解密等，具体说明如下：

    1. 数据格式处理：协商和建立数据交换的格式，解决各应用程序之间在数据格式表示上的差异。

    2. 数据的编码：处理字符集和数字的转换。例如由于用户程序中的数据类型（整型或实型、有符号或无符号等）、用户标识等都可以有不同的表示方式，因此，在设备之间需要具有在不同字符集或格式之间转换的功能。

    3. 压缩和解压缩：为了减少数据的传输量，这一层还负责数据的压缩与恢复。

    4. 数据的加密和解密：可以提高网络的安全性。

    1. 会话管理：允许用户在两个实体设备之间建立、维持和终止会话，并支持它们之间的数据交换。例如提供单方向会话或双向同时会话，并管理会话中的发送顺序，以及会话所占用时间的长短。

    2. 会话流量控制：提供会话流量控制和交叉会话功能。

    3. 寻址：使用远程地址建立会话连接。

    4. 出错控制：从逻辑上讲会话层主要负责数据交换的建立、保持和终止，但实际的工作却是接收来自传输层的数据，并负责纠正错误。会话控制和远程过程调用均属于这一层的功能。但应注意，此层检查的错误不是通信介质的错误，而是磁盘空间、打印机缺纸等类型的高级错误。

  1. 向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。传输层的作用是向高层屏蔽下层数据通信的细节，即向用户透明地传送报文。

    1. 传输连接管理：提供建立、维护和拆除传输连接的功能。传输层在网络层的基础上为高层提供“面向连接”和“面向无接连”的两种服务。

    2. 处理传输差错：提供可靠的“面向连接”和不太可靠的“面向无连接”的数据传输服务、差错控制和流量控制。在提供“面向连接”服务时，通过这一层传输的数据将由目标设备确认，如果在指定的时间内未收到确认信息，数据将被重发。

    3. 监控服务质量。

  2. 该层常见的协议：TCP/IP中的TCP协议、Novell网络中的SPX协议和微软的NetBIOS/NetBEUI协议。

  1. 通过路由选择算法，为报文或分组通过通信子网选择最适当的路径

  2. 数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。

    1. 寻址：数据链路层中使用的物理地址（如MAC地址）仅解决网络内部的寻址问题。在不同子网之间通信时，为了识别和找到网络中的设备，每一子网中的设备都会被分配一个唯一的地址。由于各子网使用的物理技术可能不同，因此这个地址应当是逻辑地址（如IP地址）。

    2. 交换：规定不同的信息交换方式。常见的交换技术有：线路交换技术和存储转发技术，后者又包括报文交换技术和分组交换技术。

    3. 路由算法：当源节点和目的节点之间存在多条路径时，本层可以根据路由算法，通过网络为数据分组选择最佳路径，并将信息从最合适的路径由发送端传送到接收端。

    4. 连接服务：与数据链路层流量控制不同的是，前者控制的是网络相邻节点间的流量，后者控制的是从源节点到目的节点间的流量。其目的在于防止阻塞，并进行差错检测。

  3. 数据链路层是解决同一网络内节点之间的通信，而网络层主要解决不同子网间的通信。例如在广域网之间通信时，必然会遇到路由（即两节点间可能有多条路径）选择问题。 

  1. 物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。

  2. 该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层

    1. MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制；

    2. LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。数据链路层的具体工作是接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层；并且，还负责处理接收端发回的确认帧的信息，以便提供可靠的数据传输。

  1. 利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。

  2. 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。

分享一张大而全的七层协议框架图

TCP/IP协议-OSI的一种“实现”

传输控制协议TCP简介

TCP报文头

说说TCP的三次握手

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接

  1. 第一次握手：建立连接时，客户端发送SYN包到服务器，并进入SYN_SEND状态，等待服务器确认。这里发送的SYN包，SYN标志位为1，seq序号初始为x

  2. 第二次握手：服务器收到SYN包，必须确认客户的SYN，同时自己也发送一个SYN包给客户端，此时服务端进入SYN_RECV状态。这里服务端发送的SYN包中SYN标志位和ACK标志位都是1，seq序号初始为y，ack为x+1（表示客户端下次再发送包seq从x+1开始）

  3. 第三次握手：客户端收到服务器的SYN+ACK的包，向服务器发送确认包，此包ACK标志位1，seq序号为x+1，ack为y+1（表示服务端下一次发送数据seq从y+1开始）。此包发送完毕，客户端和服务器端都进入ESTABLISHED状态，完成三次握手，开始数据传送。

为什么需要三次握手才能建立连接

三次握手的隐患-SYN Flood

问题描述

针对SYN Flood的防护措施

针对上述问题的解决办法

建立连接后，Client出现故障怎么办

保活机制

TCP四次挥手

挥手是为了终止连接，TCP采用四次挥手来释放连接

  1. 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN-WAIT_1状态；

  2. 第二次挥手：Server收到FIN后，发送一个ACK给client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态；Client接收到Server的FIN之后，进入FIN_WAIT_2状态；

  3. 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；

  4. 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次握手

为什么要有TIME_WAIT状态

为什么需要四次握手

服务器出现大量CLOSE_WAIT状态的原因

如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。

UDP报文结构

UDP 报文中每个字段的含义如下：

UDP特点

TCP和UDP的区别

可以从以下几个方面总结区别

TCP的滑动窗口

窗口数据的计算过程

左边是TCP发送端缓冲区，右边是接收端缓冲区，左边向右边发送数据；从发送端看，下面的长条代表发送的字节流，从左向右依次发送；从接收端看，下面的长条代表接收字节流，从左向右一次接收。

接收端可接收窗口 AdvertisedWindow 大小：

AdvertisedWindow = MaxRevBuffer - （LastByteRcvd - LastByteRead）

发送端窗口内剩余可发送的窗口 EffectiveWindow 大小：

EffectiveWindow = AdvertisedWindow - （LastByteSent - LastByteAcked）

这样计算是做最坏的打算，就是认为发送端已经接收到回执的连续最大内存到已经发送的最大内存位置的数据，还在路上没有被接收端接收；接收端的最大接收位置的都已经发送了ack，但是还没有被上层应用处理。【这里AdvertisedWindow是接收端反馈给接收端的报文头里window的值，告诉发送端接收端还可以接收多少数据；发送端根据window大小计算自己还可以发送多少数据】

TCP会话的发送方

TCP发送方，任何时候在其缓存内的数据都可以分为四类

其中Category #2 和 Category #3 组成了滑动窗口，当LastByteAcked向前移动的时候，滑动窗口才能向前移动。

TCP会话的接收方

TCP接收方，任何时候在其接收缓存内的数据都可以分为三类或叫三种状态

因为接收到的数据TCP机制会立刻ack回执，认为没有延迟，所以不存在已接收但没有回执ack的状态；

未接收但是准备接收的 Category #3 就是叫做接收窗口；接收窗口的滑动机制与发送发一致

TCP的滑动窗口总结

TCP最基本的传输可靠性来源于确认重传机制，TCP的滑动窗口的可靠性也是建立在确认重传机制的基础上的；发送窗口只有接收到接收端对本段发送窗口内字节的ack确认，才会滑动发送窗口的左边界；接收窗口只有在前面的端都确认的情况下，才移动左边界，当前面字节没有接收但是接收到后面的字节的情况下，窗口是不会移动的，并且不会对接收到的后边的字节确认，以此让对端确认这些字段是否需要重传。

滑动窗口可以按照一定的策略动态的挑战，应用程序可以根据自身的处理能力设置调整策略

HTTP简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）

HTTP工作原理

HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。

Web服务器根据接收到的请求后，向客户端发送响应信息。HTTP默认端口号为80，但是你也可以改为8080或者其他端口。

HTTP三点注意事项：

HTTP请求结构

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

HTTP响应报文

实例

下面实例是一点典型的使用GET来传递数据的实例：

客户端请求：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com 
Accept-Language: en, mi

服务端响应:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

面试题：在浏览器地址栏键入URL，按下回车之后经历的流程

  1. DNS解析：如果URL中是网址，需要向对这个网址进行域名解析，得到相应的IP地址，请求会逐层查询DNS缓存得到目的IP地址（DNS缓存由近到远依次是：浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存）

  2. TCP连接：根据IP地址和断开，找到对应的服务器，通过TCP的三次握手建立连接

  3. 发送HTTP请求：建立TCP连接后发起HTTP请求

  4. 服务器处理请求并返回HTTP报文：服务器根据请求参数得到返回结果，并返回HTTP报文

  5. 浏览器解析渲染页面：浏览器得到报文，解析HTML代码，并请求HTML代码中的资源（例如js、css等），然后渲染页面

  6. 连接结束：TCP4次挥手，HTTP断开连接

HTTP状态码

状态码分类

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：

常见的状态码：

HTTP 请求方法

GET与POST请求的区别

Cookie、Session、token

https://www.cnblogs.com/moyand/p/9047978.html

https://segmentfault.com/a/1190000017831088

Cookie

Cookie指的是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能

cookie由服务器生成，发送给浏览器，浏览器把cookie以kv的形式保存到某个目录的文本文件内，下一次请求同一网址时会把该cookie发送给服务端。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量有限

cookie的设置和发送过程：

Session

session从字面上讲，就是会话，就是服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发送请求，都带上这个标识，服务器就知道这个请求来源于谁。浏览器默认采用cookie来保存这个标识。

服务器使用session把用户信息临时保存在服务器上，用户离开网站后session会被销毁。

    注意

Token

token 也称作令牌，由uid+time+sign[+固定参数]
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

token 的认证流程与cookie很相似

分布式情况下的session和token

我们已经知道session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。

而token是无状态的，token字符串里就保存了所有的用户信息

总结

HTTPS

https://zhuanlan.zhihu.com/p/27395037

https://www.jianshu.com/p/14cd2c9d2cd2

HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS

SSL（Secure Socket Layer，安全套接字层）：SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，目前使用最广泛的是TLS 1.1、TLS 1.2。

加密算法：

  1. 对称加密：加密和解密都是使用的同一个密钥

  • 非对称加密：加密使用的密钥和解密使用的密钥是不相同的

  • 哈希算法

  • 数字签名

    • HTTPS数据传输流程

    HTTPS在传输的过程中会涉及到三个密钥：

    服务器端的公钥和私钥，用来进行非对称加密

    客户端生成的随机密钥，用来进行对称加密

    一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

    1. 客户端向服务器发起HTTPS请求，将浏览器支持的加密算法发送给服务器

    2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

    3. 服务器选择一套浏览器支持的加密算法，以证书的形式发送给客户端，其中包含服务端的公钥。

    4. 客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

    5. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

    6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密、验证哈希，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

    7. 然后服务器将加密后的密文发送给客户端。

    8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

    问题：
    1.怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

    SSL 证书，权威证书机构发布CA证书

    2.证书如何安全传输，被掉包了怎么办？

    1. 首先，数字证书内容是加密的

  • 验证证书过程是安全的

    • HTTPS和HTTP的区别

    Socket简介

    socket是对TCP/IP协议的抽象，是操作系统对外开放的接口

    Socket通信流程

    客户端：

    服务器：

    完成~

    小猿同事面试过程中，计算机网络相关的基础知识也就问了这么多，肯定还是有很多知识点和细节没有介绍到，小猿和同事们还需要继续努力深究，争取再整理更详细的知识点分析给大家~

    上一篇 下一篇

    猜你喜欢

    热点阅读