【网络篇】教你搞定计算机网络面试（一）
【面试宝典，强烈建议关注收藏阅读】
- 1、简单说一下Web工作的整个流程
- 2、ISO的七层协议与TCP/IP的四层协议
- 3、HTTP协议相关问题
- 3.1、HTTP协议基本概念
- 3.2、HTTP协议特点
- 3.3、HTTP状态码
- 3.4、与HTTP协作的服务器
- 3.5、HTTP请求方法和首部字段
- 3.6、HTTPS
- 3.7、HTTP/1.1、HTTP/2、HTTP/3 演变
- 作者寄语
本篇是Java工程师面试方面的一些计算机网络知识的整理，当然肯定不能囊括全部知识点，但是博主会根据自身面试经验以及工作经验来总结最常用、最经典的知识点，来方便大家进行系统化的学习，博主会持续更新更多文章，觉得不错的可以点个关注
先来给大家上个图，HTTP的面试常问知识点：
1、简单说一下Web工作的整个流程
当我们在浏览器的地址栏输入 www.google.com ，然后回车，回车这一瞬间到看到页面到底发生了什么呢？
应用层域名解析（DNS）–发起TCP的三次握手–建立TCP连接之后客户端发起HTTP请求–传输层协议（例如TCP）将请求报文分割发送–网络层协议找到对方地址（边中转边传送）–服务器应答–服务器四次挥手断开TCP连接（浏览器收到返回结果解析渲染页面）
步骤的详细过程下面会讲解（面试的时候可以主动去解释）。
2、ISO的七层协议与TCP/IP的四层协议
OSI七层协议和TCP/IP协议是对当前网络协议的不同阐述：OSI七层分别是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。TCP/IP四层分为应用层、传输层、网络层以及数据链路层。
《TCP-IP详解卷一：协议》中记载：最开始网络界是没有协议的，但厂商生产必须要有协议，于是几个厂商自己定了标准，即TCP/IP协议，包括链路层，网络层，传输层和应用层。但这个构架是相对粗的划分，而且不是国际标准——ISO标准。于是OSI七层协议被专门的标准制定机构发布了，目的是取代原有的TCP/IP协议成为业界的标准，但由于TCP/IP协议已经被广大厂商所使用，所以OSI并没有得到企业的采用。OSI相对较TCP/IP来说，多了一个物理层，而把TCP/IP的应用层细化：会话层，表示层，应用层。其实TCP/IP更实用，现实中企业实现很难区分会话层，表示层和应用层。
结合互联网情况，自上而下介绍一下各层的作用：
- 应用层：应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。
常用协议：超文本传输协议HTTP、简单邮件传输协议SMTP、域名系统DNS、文本传输协议FTP、远程登陆协议Telnet
- 传输层：运输层（transport layer）的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
常用协议：传输控制协议TCP、用户数据报文协议UDP
- 网络层：在网络中通信的两个计算机之间可能会经过很多个数据链路，网络层的任务就是选择合适的路由和结点， 确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。
常用协议：网际协议IP、地址转换协议ARP、Internet控制报文协议ICMP、路由信息协议RIP
- 数据链路层：两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如：同步信息，地址信息，差错控制等）。
常用协议：点对点协议PPP、自动重传请求协议ARQ）、停止等待协议CSMA/CD
3、HTTP协议相关问题
3.1、HTTP协议基本概念
HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。
- HTTP 传输的内容是超文本，就是超越了普通文本的文本，它是文字、图片、视频等的混合体最关键有超链接，能从一个超文本跳转到另外一个超文本。HTML 就是最常见的超文本了，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等的链接，在经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。
- 所谓的「传输」，很好理解，就是把一堆东西从 A 点搬到 B 点，或者从 B 点 搬到 A 点。HTTP 协议是一个双向协议，是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。
- 协议代表的是必须有两个以上参与的行为的约定和规范。
3.2、HTTP协议特点
- 灵活可扩展：HTTP协议是一个“灵活可扩展”的传输协议。
- 可靠传输：因为HTTP协议是基于TCP/IP的，而TCP本身是一个“可靠”的传输协议，所以HTTP自然也就继承了这个特性，能够在请求方和应答方之间“可靠”地传输数据。
- 应用层协议：HTTP属于应用层的协议，采用明文传输，HTTP具有可携带任意头字段和实体数据的报文结构，以及连接控制、缓存代理等方便易用的特性，成为了应用层里的“明星”协议。
- 客户端-服务端模式：HTTP协议使用的是请求-应答通信模式。请求-应答模式也明确了HTTP协议里通信双方的定位，永远是请求方先发起连接和请求，是主动的，而应答方只有在收到请求后才能答复，是被动的，如果没有请求时不会有任何动作。
- 无状态：HTTP协议是无状态的。“状态”其实就是客户端或者服务器里保存的一些数据或者标志，记录了通信过程中的一些变化信息。“无状态”形象地来说就是“没有记忆能力”。
HTTP协议中的明文传输和无状态是一把双刃剑，因为同时还会有缺点不安全和一些麻烦。无状态会导致服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。比如经典的购物车问题，解决办法就是我们常用的Cookie和Session。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie中存储JSessionID，可以去服务端获取相应的Session。
3.3、HTTP状态码
HTTP状态码可以说是在实际开发中很重要的一个点了，面试频率也是非常高的，了解常见的状态码是必要的。
状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：
接下来介绍最常见的状态码：
- 200 OK：表明请求被正常处理。
- 204 NO Content：代表服务器接收的请求已成功处理，但在返回的报文中不包含实体的主体部分。
- 206 Partial Content：表明客户端进行了范围请求，而服务器成功执行了这部分的GET请求。
- 301 Moved Permanetly：永久重定向，请求的资源已经分配了新的URI，以后使用资源现在所指的URI。
- 302 Found：临时重定向，请求的资源已经分配了新的URI，希望用户能使用新的URI。
- 303 See Other：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上。
- 304 Not Modified：发送附带条件的请求时，条件不满足时返回，与重定向无关
- 307 Temporary Redirect：临时重定向，与302类似，只是强制要求使用POST方法。
- 400 Bad Request：请求报文语法有误，服务器无法识别。
- 401 Unauthorized：请求需要认证。
- 403 Forbidden：请求的对应资源禁止被访问。
- 404 Not Found：服务器无法找到对应资源。
- 500 Internal Server Error：服务器内部错误。
- 503 Service Unavailable：服务器正超负载或者停机维护，无法处理请求。
状态码和状况的不一致：不少返回的状态码响应都是错误的，但是用户可能察觉不到。比如web程序内部错误，但状态码仍然返回200。
3.4、与HTTP协作的服务器
HTTP通信时，除客户端和服务端以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。他们可以配合服务器工作，这些应用程序和服务器可以将请求转发个通信线路上的下一站服务器，并且能接收从那台服务器发送的响应在转发给客户端。
- 代理：代理是一种由转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，不改变请求的URI，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
- 网关：网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的服务器一样对请求进行处理。有时客户端可能都不会察觉，自己的通讯目标是一个网关。网关可以提供非HTTP协议服务，利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。
- 隧道：隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。隧道的目的是确保客户端能与服务端进行安全的通信，隧道本身不回去解析HTTP请求，也就是说，请求保持原样中转给之后的服务器，隧道会在通信双方断开连接时结束。
3.5、HTTP请求方法和首部字段
先解释一下统一资源标志符URI和统一资源定位符URL：URI是Uniform Resource Identifier的缩写，在某一规则下能把一个资源独一无二地标识出来。URL表示资源的地点（互联网所处的位置），URL是URI的子集。
举个例子：比如人，身份证号是独一无二的，通过身份证号能让我们能且仅能确定一个人，身份证号即代表统一资源定位符URI。一个人的住址，即代表统一资源定位符URL。
HTTP请求方法：
Get请求和Post请求的区别：
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
- GET请求在URL中传送的参数是有长度限制的，而POST没有。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。GET请求只能进行url编码，而POST支持多种编码方式。
- GET参数通过URL传递，POST放在Request body中，GET比POST更不安全。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET产生一个TCP数据包；POST产生两个TCP数据包。
对于这个问题，我们需要更深层次的解释才能真正俘获面试官的“芳心”，耐心读下去。
HTTP报文：
用于HTTP交互的信息被称为HTTP报文，请求端的HTTP报文叫做请求报文，响应端的HTTP报文叫做响应报文，HTTP报文本身是由多行数据构成的字符串文本。HTTP报文大致可以分为报文首部和报文主题两部分，两者由空行来分割，报文主体不一定要有。
-
请求报文：请求行+请求头+请求体；请求行包含用于请求的方法、请求URI和HTTP版本，请求头包含请求的各种条件和属性的各类首部，请求体即报文主体。
-
响应报文：响应行+响应头+响应体；响应行包含表明响应结果的状态码、原因短语和HTTP版本，响应头包含响应的各种条件和属性的各类首部，响应体即报文主体。
HTTP首部字段：
HTTP首部字段根据实际用途分为4种类型：通用首部字段，请求首部字段，响应首部字段，实体首部字段。
- 通用首部字段：请求报文和响应报文两方都会使用到的首部。
- 请求首部字段： 从客户端向服务器发送请求报文时使用的首部，补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
- 响应首部字段： 从服务器端向客户端返回响应报文时使用的首部，补充了响应时的附加内容，也会要求客户端附加额外的内容信息。
- 实体首部字段： 针对请求报文和响应报文的实体部分使用到的首部，补充了资源内容更新时间等与实体有关的信息。
3.6、HTTPS
说到HTTPS，需要先说一下HTTP的缺点：
- 通信使用明文不加密，内容可能被窃听。由于HTTP本身不具有加密功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和相应内容）进行加密。即HTTP使用明文（未进行加密）进行传递。
- 不验证通信方身份，可能遭到伪装。HTTP协议中的请求和响应不会对通信方进行确认，也就是说存在“服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际请求的客户端”等类似问题。
- 无法验证报文完整性，可能被篡改。完整性即信息的准确度，若无法证明其完整度，通常也就意味着无法判断信息是否准确。
HTTPS=HTTP+加密处理（一般是SSL安全通信线路）+认证+完整性保护，HTTPS并非是一个新协议，只是在HTTP通信接口部分用SSL和TSL协议代替而已。通常是HTTP先和TCP通信，当使用SSL时，演变成先和SSL通信，再由SSL和TCP通信。
HTTPS如何解决HTTP不安全问题？
简单说下，HTTPS并非是一个新协议，只是HTTP通信接口部分用SSL和TLS协议代替而已。通常的是HTTP和TCP（或者UDP等）直接通信，当使用SSL时，则变成先和SSL通信，再由SSL和TCP通信。
采用了SSL之后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。
HTTPS是如何建立连接的，其间交互了什么？
- 在使用HTTPS是需要保证服务端配置正确了对应的安全证书；
- 客户端发送请求到服务端；
- 服务端返回公钥和证书到客户端；
- 客户端接收后会验证证书的安全性,如果通过则会随机生成一个随机数,用公钥对其加密,发送到服务端；
- 服务端接受到这个加密后的随机数后会用私钥对其解密得到真正的随机数,随后用这个随机数当做私钥对需要发送的数据进行对称加密；
- 客户端在接收到加密后的数据使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户；
- SSL加密建立。
那为什么还有很多网站都使用HTTP呢？
- HTTPS 连接服务器端资源占用高。
- HTTPS 协议握手费时：多几次握手，网络耗时变长，用户从 HTTP 跳转到 HTTPS 还要一点时间。
- SSL 证书费用：不少用户觉得开启 HTTPS 要申购 SSL 证书，每年要在证书上花费不菲的费用。
3.7、HTTP/1.1、HTTP/2、HTTP/3 演变
HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
- 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持 管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。那 HTTP/2 相比 HTTP/1.1 性能上的改进：
- 头部压缩：HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的分。
- 二进制格式：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。
- 数据流：每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数。
- 多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。
作者寄语
本文介绍了网络的一些面试经历，下一篇我们来介绍TCP和UDP等网路知识点，欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，感激不尽。
你知道的越多，你不知道的也越多。keep hungry keep foolish！
看完之后感觉如何，觉得不错的可以关注湿兄一波，湿兄会持续给大家更新更多湿的文章~
