Welcome to xpt’s blog! 2021年准备秋招期间整理的一些笔记，分享给大家！

文档分享的初衷是给师弟师妹们作为参考，主要是适合想去大厂+测试开发岗的朋友们。
建议大家自己整理文档，把我的文档作为参考，有些东西自己整理，自己去写出来，才是最适合你自己的！
文章还未精细整理，如存在错误之处，可以邮件or微信反馈给我呀，感激不尽！

想进大厂，要抓住提前批免笔试的机会！（例如京东、字节、百度等报名时间一般为七月，面试时间为报名后的一周内，面试一般为3轮，面试相关经验后续我会单独再写blog分享^_^，也欢迎大家来跟我talk，一定知无不言。）

本人情况：普通211、研究生、有京东、百度、以及字节提前批测开岗offer。7月初开始准备，准备太迟，一边准备一边投简历+面试。

投递简历时间：京东（7.14），字节（7.30），百度（7.30）
三轮面试时间：京东（7.21-7.22-7.26），字节（8.4-8.6-8.9），百度（8.9-8.12-8.16）
意向书时间：京东（8.12），字节（8.16），百度（9.9）

京东提前批开始很早，我投的时候已经是第二批。经过京东几轮面试，熟悉了面试流程，大概掌握了测开岗会问些什么问题。
字节和百度提前批我是在ddl前一天投递，其实已经算很迟了，hc不多了。
投递要趁早，很多岗位有固定hc。
多拿offer，才有谈薪资的底气。

我面试的岗位有以下：
1、测试开发岗（京东、百度、以及字节提前批）
2、银行java开发岗（所以我会整理一点java，银行问的都很简单，所以我这里对java的整理比较少）

整理的内容均来源于历年网络上分享的面经（主要来源于牛客），以及我面试时被问过的问题，list如下：
(1)——计算机网络
(2)——操作系统
(3)——数据库
(4)——数据结构
(5)——python
(6)——java
(7)——linux
(8)——常考编程题
(9)——测试开发相关知识

面试QA整理(1)——计算机网络

http协议

请你来说一说http协议

HTTP (Hyper Text Transfer Protocol,超文本传输协议)

是用于web服务器和本地浏览器之间传输文件的传输协议，

是一个基于请求与响应模式的、无状态的、应用层的协议，

是一个基于TCP/IP通信协议来传递数据（HTML 文件，图片文件，查询结果等）的协议

HTTP协议工作于客户端-服务端架构之上。

浏览器作为HTTP客户端通过URL，向HTTP服务端，即WEB服务器发送所有请求。Web服务器根据接收到的请求，向客户端发送响应信息。

HTTP工作流程

1、客户端与服务器建立TCP连接。
2、客户端向服务器发出请求。
3、服务器接收到客户端的请求，根据请求向客户端返回响应内容。
4、客户端接收服务器的响应内容，解析内容在前端展示;然后客户端与服务断开连接。

HTTP协议特点

1、简单快速:客户向服务器请求服务时，只需传送请求方法和路径。

2、灵活: HTTP允许传输任意类型的数据对象。

3、**无状态，不保存状态:**无状态是指协议对于事务处理没有记忆能力。缺少状态意味着：如果后续处理需要前面的信息，则它必须重传。

4、无连接的：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。也就是服务器处理完一次请求后会关闭连接。

5、支持B/S及C/S模式。【支持客户端C/服务器S模式，浏览器B/服务器S模式】

6、默认端口80

7、基于TCP/IP通信协议

HTTP工作流程

1、客户端与服务器建立TCP连接。
2、客户端向服务器发出请求。
3、服务器接收到客户端的请求，根据请求返回响应内容。
4、客户端接收服务器的响应内容，解析内容在前端展示;然后客户端与服务
器断开连接。

HTTP特点

1、简单快速:客户向服务器请求服务时，只需传送请求方法和路径。

请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。
由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2、灵活: HTTP允许传输任意类型的数据对象。

正在传输的类型由Content-Type加以标记。

3、**无状态，不保存状态:**无状态是指协议对于事务处理没有记忆能力。缺少状态意味着：如果后续处理需要前面的信息，则它必须重传。

缺点:可能导致每次连接传送的数据量增大。
优点:在服务器不需要先前信息时应答较快，减少服务器CPU和内存的消耗。
引入cookie和session机制:Cookie在客户端记录信息确定用户身份，Session在服务器端记录信息确定用户身份。

4、无连接的:限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。

缺点:每次请求都要建立\断开TCP连接，通信量开销增大。
优点:采用这种方式可以节省传输时间。
后续引进持久连接(HTTP keep-alive) :在一次TCP连接中可以持续发送多份数据而不会断开连接，减少tcp连接建立次数;一般服务端会设置keep- alive timeout最大连接数
keep- alive timeout:传送完后超过这个时间就关闭连接
最大连接数:到达最大连接数后，有新请求发起连接，未达到超时也会关闭前面的连接

5、支持B/S及C/S模式。【支持客户端C/服务器S模式，浏览器B/服务器S模式】

6、默认端口80

7、基于TCP/IP通信协议，

HTTP使用的是可靠的数据传输协议(底层是tcp协议，确保顺序内容的正确，确保没有丢包)，因此
即使数据来自地球的另- -端，它也能够确保数据在传输的过程中不会被损坏或产生混乱。这样，用户在
访问信息时就不用担心其完整性了，因此对用户来说，这是件好事。

HTTP的缺点

1、被窃取: Http通信使用明文，传输过程中没有任何的加密措施，可能会被窃听。
2、被伪装:在传输过过程中，不验证通信方的身份，这中间就有可能被伪装
3、被篡改: Http只是对报文进行了解析，并没有对其进行完整的校验，所以无法验证报文
的完整形，可能被遭篡改

通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

报文

➢HTTP报文是由一行一行的简单字符串组成的。
➢HTTP报文都是纯文本，不是二进制代码，所以人们可以很方便地对其进行读写。
➢从Web客户端发往Web服务器的HTTP报文称为请求报文(request message)
➢从服务器发往客户端的报文称为响应报文(response message)。

一个http请求报文由请求行（request line）、请求头部（header）、空行和请求数据4部分组成。

一个http响应由状态行、响应头部、空行和响应数据4部分组成。

HTTP常见的请求头里有什么内容？

HTTP请求方式，请求Web服务器的目录地址，HTTP协议版本
Accept:浏览器可接受的数据类型;
- 客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Accept-Charset:浏览器可接受的字符集;
Accept-Encoding:浏览器能够进行解码的数据编码方式，比如gzip。 Servlet能够向支持gzip的浏
览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间; .
Accept-Language:浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到;
Authorization:授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中;
Connection:表示是否需要持久连接。如果Servlet看到这里的值为”Keep-Alive“,或者看到请求使
用的是HTTP 1.1 (HTTP 1.1默认进行持久连接)，它就可以利用持久连接的优点，当页面包含多个元素
时(例如Applet, 图片)，显著地减少下载所需要的时间。要实现这一点， Servlet需要在应答中发送一
个Content-Length头，最简单的实现方法是:先把内容写入ByteArrayOutputStream,然后在正式写出
内容之前计算它的大小;
- HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。
Content-Length:表示请求消息正文的长度;
Cookie:这是最重要的请求头信息之一;
From:请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它;
Host:初始URL中的主机和端口;
If-Modified- Since:只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304”Not
Modified”应答;
Pragma:指定”no- cache”值表示服务器必须返回-个刷新后的文档，即使它是代理服务器而且已经
有了页面的本地拷贝;
Referer:包含一个URL,用户从该URL代表的页面出发访问当前请求的页面。
User-Agent:浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用;
UA-Pixels, UA-Color, UA-OS, UA-CPU: 由某些版本的IE浏览器所发送的非标准的请求头，表示
屏幕大小、颜色深度、操作系统和CPU类型。

HTTP常见的响应头里有什么内容？

Allow:服务器支持哪些请求方法(如GET、POST等) ;
Content-Encoding:Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
- 文档的编码(Encode) 方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows.上的IE4、IE 5才支持它。因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader(“Accept-Encoding’”)) 检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面;
Content-Length:表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想
要利用持久连接的优势，可以把输出文档写入ByteArrayOutputStram,完成后查看其大小，然后把该值
放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream)发送内容;
Content-Type:Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。Servlet默认为text/plain, 但通常需要显式地
指定为text/html。由于经常要设置Content-Type,因此HttpServletResponse提供了一个专用的方法
setContentTyep。可在web.xml文件中配置扩展名和MIME类型的对应关系;
Date:当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦;
Expires:指明应该在什么时候认为文档已经过期，从而不再缓存它。
Last-Modified:文档的最后改动时间。客户可以通过lf-Modified- Since请求头提供一个日期, 该请
求将被视为一个条件GET,只有改动时间迟于指定时间的文档才会返回，否则返回-个304 (Not
Modified)状态。, Last-Modified也可用setDateHeader方法来设置;
Location:表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过
HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302;
Refresh:表示浏览器应该在多少时间之后刷新文档，以秒计。

什么是Cookie？Cookie用来干什么的？

1.Cookie是什么？

cookie是浏览器支持的一种本地存储机制。一般由服务端设置生成，在响应请求时被自动存储在浏览器中。

2.为什么会有Cookie的存在？

cookie是为了辨别用户身份的。我们知道HTTP本身是无状态的协议，服务端不会记得是谁向它发来的请求。但在某些情况下我们需要记住用户在未登录的状态下浏览了什么，比如淘宝。这时候就需要借助我们的Cookie了。客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。

http是无状态协议，——服务器不记录谁访问过它，减少服务器的压力(减少维护信息)
那么服务端如何识别特定的客户端呢?

1.每次http请求的时候，客户端（在请求头里）都会发送相应的cookie信息到服务端
2.实际.上大多数应用都是用cookie来实现session跟踪的，
第一次创建session的时候，服务端会在http协议中告诉客服端，需要在cookie里记录一个sessionid, 以后每次请求把这个id发送到服务器，我就知道你是谁了
3.如果客户端禁用cookie怎么办?一般这种情况下，会使用一种叫做url重写的技术来进行会话跟踪，即
每次http交互，url后面都会被附加上一个诸如sid=**的参数，服务端据此来识别用户。

虽然Cookie和Session都可以跟踪客户端的访问记录，但是它们的工作方式显然是不同的，

【cookie为什么不安全】

Cookie通过把所有要保存的数据通过HTTP协议的头部从客户端传递到服务端，又从服务端再传回到客
户端，所有的数据都存储在客户端的浏览器里，所以这些Cookie 数据可以被访问到，不仅可以查看
Cookie,甚至可以通过插件添加、修改Cookie, 所以Cookie 的安全性受到了很大的挑战。
相比较而言Session的安全性要高很多，因为Session是将数据保存在服务端，只是通过Cookie传递
一个SessionID而已，所以Session 更适合存储用户隐私和重要的数据。

Cookie和Session的区别

简单阐述：

cookie 是把用户的数据写给用户浏览器， session 是把用户的数据写到用户独占的 session 中

Cookie存储在客户端阅读器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正 Cookie中的内容。
而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险

session 对象由服务器创建，开发人员可以调用 request 对象的 getsession 方法得到 session 对象
cookie 不是很安全，别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗,如果主要考虑到安全应当使用 session。【隐私策略的不同】
session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用 COOKIE 【服务器压力的不同】

详细阐述：

1.存取方式的不同

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二进制数据，需求先进行编码。
Cookie中也不能直接存取Java对象。若要存储略微复杂的信息，运用Cookie是比较艰难的。
而Session中能够存取任何类型的数据，包括而不限于String、Integer、List、Map等。
Session中也能够直接保管Java Bean乃至任何Java类，对象等，运用起来十分便当。能够把Session看做是一个Java容器类。

2.隐私策略的不同

Cookie存储在客户端阅读器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正 Cookie中的内容。
而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。
假如选用Cookie，比较好的方法是，敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密，提交到服务器后再进行解密，保证Cookie中的信息只要本人能读得懂。
而假如选择Session就省事多了，反正是放在服务器上，Session里任何隐私都能够有效的保护。

3.有效期上的不同

使用过Google的人都晓得，假如登录过Google,则Google的登录信息长期有效。用户不用每次访问都
重新登录，Google会持久地记载该用户的登录信息。
要到达这种效果，运用Cookie会是比较好的选择。只需要设置Cookie的过期时间属性为一个很大很大的数字。
由于Session依赖于名为JSESSIONID的Cookie,而Cookie JSESSIONID的过期时间默许为-1，只需关闭
了阅读器该Session就会失效，因而Session不能完成信息永世有效的效果。运用URL地址重写也不能完
成。
而且假如设置Session的超时时间过长，服务器累计的Session就会越多，越容易招致内存溢出。

4.服务器压力的不同

Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十
分多的Session,耗费大量的内存。
因而像Google、Baidu、 Sina这样并发访问量极高的网站，是不太可能运用Session来追踪客户会话的。
而Cookie保管在客户端，不占用服务器资源。
假如并发阅读的用户十分多，Cookie是很好的选择。关于Google、Baidu、 Sina来说， Cookie或许是唯一的选择。

5.浏览器支持的不同

Cookie是需要客户端浏览器支持的。假如客户端禁用了Cookie,或者不支持Cookie,则会话跟踪会失
效。
- 关于WAP上的应用，常规的Cookie就派不上用场了。
假如客户端浏览器不支持Cookie，需要运用Session以及URL地址重写。需要注意的是一切的用到
Session程序的URL都要进行URL地址重写，否则Session会话跟踪还会失效。
- 关于WAP应用来说，Session+URL地址重写或许是它唯一的选择。
假如客户端支持Cookie,则Cookie既能够设为本浏览器窗口以及子窗口内有效(把过期时间设为-1)，
也能够设为一切阅读器窗口内有效(把过期时间设为某个大于0的整数)。但Session只能在本阅读器窗
口以及其子窗口内有效。假如两个浏览器窗口互不相干，它们将运用两个不同的Session。(IE8 下不同
窗口Session相干)

6.跨域支持上的不同

Cookie可以通过如下方式实现跨域名访问，例如将domain属性设置为”.xxx.com”,则”a.xxx.com”和
“b.xxx.com”均能够访问该Cookie。事实上只要是以.xx.com”结尾的域名均可访问。跨域名Cookie如今
被普遍用在网络中，例如Google、 Baidu、 Sina等。
而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。

HTTP请求命令，http有哪些请求方式，HTTP方法

➢HTTP支持几种不同的请求命令,这些命令被称为HTTP方法(HTTP method)。
➢每条HTTP请求报文都包含一个方法。
➢这个方法会告诉服务器要执行什么动作(获取一个Web页面、运行一个网关程序、删除一个文件等)
常见的HTTP方法:

HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。

☆GET和POST的区别

GET重点在从服务器上获取资源，一般用于获取/查询资源信息，是无副作用的，是幂等的，且可缓存；

而POST重点在向服务器发送数据，一般用于更新资源信息。有副作用，非幂等，不可缓存。
post比get安全性更高。
Get通过URL来传输数据，因为URL是可见的，可能会泄露私密信息，如密码等

GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如http://127.0.0.1/est/login. action?name= admin&password=admin这个过程用户是可见的

POST通过URL和请求体requrest body传输数据，将字段与对应值封存在请求体中发送给服务器。在请求体中的数据，我们是无法直接观测到的。
在安全性上，GET没有POST安全。但是他们都不是绝对安全。因为POST中的数据，可以通过抓包获取
在数据大小上，GET有限制，而POST没有上限。
Get传输的数据量小，因为URL长度受浏览器及服务器的限制，但效率较高；
Post可以传输大量数据，所以上传文件时都用Post方式;
对于参数的数据类型
GET只接受ASCII字符， 向服务器传的中文字符可能会乱码
而POST没有限制
GET请求会被浏览器主动cache（缓存），而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark（可收藏为书签），而POST不可以。

POST 方法会产生两个TCP数据包？

header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。
简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。
长的说：对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。但是，

GET与POST都有自己的语义，不能随便混用。
据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
并不是所有浏览器都会在POST中发送两次包，Firefox，Chrome都只发送一次。

get和post在哪里传参

☆get的幂等性由什么保证？（安全和幂等

在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

GET 方法就是安全且幂等的，get通常都是查询，不涉及数据修改。因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

　(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。

注意：这里安全的含义仅仅是指是非修改信息。

　(2).幂等的意味着对同一URL的多个请求，不应有副作用，不会改变资源。

这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。比如：访问百度，这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用。

☆常见响应状态码

例如：200（成功）/300（重定向别的地方）/400（请求语法错误）/500（服务器异常）

1xx:指示信息，表示请求已接收，还需要后续操作，继续处理。
2xx:成功，表示请求已被成功接收、理解、接受。
3xx:重定向，要完成请求必须进行更进一步的操作。客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源
4xx:客户端错误，请求有语法错误或请求无法实现。
5xx:服务器端错误，服务器未能实现合法的请求。

「200 OK」是最常见的成功状态码，如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

「500 Internal Server Error」是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

浏览器输入一个URL之后，网络各层发生了什么？（输入url涉及哪些协议、DNS过程

访问一个完整http请求会经历哪些步骤?
一个完整的http请求主要有六个步骤:

1.输入url后，将url发送给dns, 域名解析(DNS服务) ，根据域名找到服务器的ip地址,和端口号
2.发起TCP的3次握手,
3.建立TCP连接后发起http请求，发送header, body等信息
4.服务器端响应http请求，将资源封装成响应包返回，服务器返回完了之后会进行四次挥手，关闭连接，浏览器得到html代码
5.浏览器解析html代码，并请求html代码中的资源，浏览器拿到返回包做解析，比如会收到图片，js, css等，然后再次发送http请求，拿到这些数据，最终显示出这些内容
6.浏览器对页面进行渲染呈现给用户。

发送端由应用层往下走，接收端由数据链路层往上走，步骤如下：

１、浏览器输入url，若协议为 http，
２、应用层 DNS 解析，返回对应的 ip 地址（DNS协议，DNS服务器是基于UDP的，因此会用到UDP协议。
３、应用层客户端发送 http 请求，（http协议
４、传输层传输报文建立tcp连接，（TCP协议
５、网络层 ip 查询mac地址（IP协议，ARP协议
６、数据到达数据链路层
7、物理层：物理传输bit。
8、服务器端经过物理层→数据链路层→网络层→传输层→应用层，解析请求报文，发送HTTP响应报文。
9、关闭连接，TCP四次挥手。
10、客户端解析HTTP响应报文，浏览器开始显示HTML

输入url涉及哪些协议

浏览器要将URL解析为IP地址，解析域名就要用到DNS协议，首先主机会查询DNS的缓存，如果没有就给本地DNS发送查询请求。DNS查询分为两种方式，一种是递归查询，一种是迭代查询。如果是迭代查询，本地的DNS服务器，向根域名服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议。

得到IP地址后，浏览器就要与服务器建立一个http连接。因此要用到http协议。http生成一个get请求报文，将该报文传给TCP层处理，所以还会用到TCP协议。如果采用https还会使用https协议先对http数据进行加密。TCP层如果有需要先将HTTP数据包分片，分片依据路径MTU和MSS。

TCP的数据包然后会发送给IP层，用到IP协议。IP层通过路由选路，一跳一跳发送到目的地址。当然在一个网段内的寻址是通过以太网协议实现(也可以是其他物理层协议，比如PPP，SLIP)，以太网协议需要直到目的IP地址的物理地址，有需要ARP协议。ARP（地址解析协议）ARP解决的是同一个局域网内，主机或路由器的IP地址和MAC地址的映射问题。

网络各层发生了什么？（详细描述）
1、查询DNS，获取域名对应的IP。
（1）检查浏览器缓存、检查本地hosts文件是否有这个网址的映射，如果有，就调用这个IP地址映射，解析完成。
（2）如果没有，则查找本地DNS解析器缓存是否有这个网址的映射，如果有，返回映射，解析完成。
（3）如果没有，则查找填写或分配的首选DNS服务器，称为本地DNS服务器。服务器接收到查询时：
如果要查询的域名包含在本地配置区域资源中，返回解析结果，查询结束，此解析具有权威性。
如果要查询的域名不由本地DNS服务器区域解析，但服务器缓存了此网址的映射关系，返回解析结果，查询结束，此解析不具有权威性。
（4）如果本地DNS服务器也失效：
如果未采用转发模式（迭代），本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后，会判断这个域名（如.com）是谁来授权管理，并返回一个负责该顶级域名服务器的IP，本地DNS服务器收到顶级域名服务器IP信息后，继续向该顶级域名服务器IP发送请求，该服务器如果无法解析，则会找到负责这个域名的下一级DNS服务器（如http://baidu.com）的IP给本地DNS服务器，**循环往复直至查询到映射**，将解析结果返回本地DNS服务器，再由本地DNS服务器返回解析结果，查询完成。

如果采用转发模式（递归），则此DNS服务器就会把请求转发至上一级DNS服务器，如果上一级DNS服务器不能解析，则继续向上请求。最终将解析结果依次返回本地DNS服务器，本地DNS服务器再返回给客户机，查询完成。

2、得到目标服务器的IP地址及端口号（http 80端口，https 443端口），会调用系统库函数socket，请求一个TCP流套接字。客户端向服务器发送HTTP请求报文：
（1）应用层：客户端发送HTTP请求报文。
（2）传输层：（加入源端口、目的端口）建立连接。实际发送数据之前，三次握手客户端和服务器建立起一个TCP连接。
（3）网络层：（加入IP头）路由寻址。
（4）数据链路层：（加入frame头）传输数据。
（5）物理层：物理传输bit。
3、服务器端经过物理层→数据链路层→网络层→传输层→应用层，解析请求报文，发送HTTP响应报文。
4、关闭连接，TCP四次挥手。
5、客户端解析HTTP响应报文，浏览器开始显示HTML

理解URL，以及URL的组成部分

Uniform Resoure Locator
资源定位符

就以下面这个URL为例，介绍下普通URL的各部分组成

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

从上面的URL可以看出，一个完整的URL包括以下几部分：
**1.**协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在”HTTP”后面的“//”为分隔符

**2.**域名部分：该URL的域名部分为“aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用

**3.**端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口

**4.**虚拟目录部分：从域名后的第一个“/”最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

**5.**文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名

**6.**锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

**7.**参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

☆http和https的区别

HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是使用密钥进行加密（经过SSL/TLS加密）的，所以HTTPS具有更高的安全性。
HTTPS部署成本高，HTTPS 协议需要使用证书来验证自身的安全性，所以需要购买CA证书，一般免费证书较少，功能越强的证书，越贵，因而需要一定费用。
HTTPS握手阶段延时较高：HTTPS在TCP三次握手阶段之后，还需要进行SSL/TLS的handshake（握手），协商加密使用的对称加密密钥，有统计延长大概50%
https会更多占用服务器的连接资源：由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高
https在缓存方面，不如http
HTTP协议端口是80，HTTPS协议端口是443

☆ssl具体握手过程（https流程，具体是怎么连接的）https是如何实现安全的

https是如何实现安全的

信息加密：交互信息无法被窃取。混合加密的方式实现信息的机密性，解决了窃听的风险。
校验机制：无法篡改通信内容，篡改了就不能正常显示。摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。
身份证书：证明服务端是真的服务端。将服务器公钥放入到数字证书中，解决了冒充的风险。

SSL/TLS 协议基本流程：（前两步也就是 SSL/TLS 的建立过程，也就是握手阶段

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

！！！！！！SSL/TLS 协议建立的详细流程：

（1）client_hello，客户端发起请求，
以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息
（2）server_hello+server_certificate+sever_hello_done
server_hello, 服务端产生第一次应答，服务端返回协商的信息结果，包括选择使用的协议版本，选择的加密套件，选择的压缩算法、随机数等，其中随机数用于后续的密钥协商;
server_certificates, 服务端向客户端发送自己的证书，用于身份验证与密钥交换；客户端验证证书的合法性，如果验证通过才会进行后续通信。
server_hello_done，通知客户端 server_hello 信息发送结束;（一个空的指令，仅表示结束。）
（3）client_key_exchange+change_cipher_spec+encrypted_handshake_message
client_key_exchange，合法性验证通过之后，客户端计算产生一个随机数字 Pre-master，并用证书公钥加密，发送给服务器;（此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数与自己计算产生的 Pre-master，计算得到协商密钥;）
change_cipher_spec，这步是一个提示，相当于客户端告诉服务端，后续的通信都采用协商的密钥与算法进行加密通信;
encrypted_handshake_message，该报文包含连接至今全部报文的整体校验值，采用协商密钥与算法进行加密，然后发送给服务器用于数据与握手验证;（这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准）
（4）change_cipher_spec+encrypted_handshake_message
服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数，计算得到协商密钥。然后解密客户端发送的报文，验证数据和密钥正确性;
验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥与算法加密并发送到客户端;
（5）握手结束
客户端采用协商密钥解密服务器发来的报文，验证服务器发送的数据和密钥，验证通过则握手完成，SSL连接就算建立完成。
（6）加密通信，开始使用协商密钥与算法进行加密通信。

下图为wireshark中捕获的一个完整的握手过程，29为客户端，193为服务端。

https如何验证证书

客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这就存在些问题，如何保证公钥不被篡改和信任度？

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的

https为什么要先非对称再对称

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

客户端在使用HTTPS方式与Web服务器通信时的步骤

　（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

　（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

　（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

　（5）Web服务器利用自己的私钥解密出会话密钥。

　（6）Web服务器利用会话密钥加密与客户端之间的通信。

http明文传输，不安全。传输过程中被截获直接就能读取信息

为解决这个问题就在http的基础上加入SSL协议。SSL,安全套接字协议，它是靠证书来验证服务端的身份，并在本地机和服务端之间架起一条通道。

简单说，你使用https访问一个网站，这网站会给你发一个证书。过证书告诉你，这网站没问题。

然后网站生成一个箱子，还有二把钥匙。然后把箱子和其中一把钥匙给你，网站自己留另一把。

然后你把信息放箱子里加密了,再用钥匙锁上，发给网站。网站接收之后，它再用另一把钥匙打开箱子，拿到信息。困为你的信息被SSL套住了,坏人中途劫持信息，也打不开。

HTTPS优点和缺点

HTTPS优点：

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高
HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器

HTTPS缺点：

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加
HTTPS部署成本高：
- HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；
- 由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高

HTTPS缺点：

SSL证书是要收费的。而且功能越强的证书，越贵
SSL会延长页面的加载时间，有统计延长大概50%
https在缓存方面，不如http
https会更多占用服务器的连接资源
https在面对黑客攻击、Dos拒绝服务攻击等方面也没啥作用

SSL与TLS

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

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 性能上的改进：

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

5. 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP/2 主要的问题在于，多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的一个丢包全部重传问题。

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

如何利用UDP实现可靠传输（基于 UDP 的 QUIC 协议）

QUIC : Quick UDP Internet Connection

应用层协议

1.自定义连接机制
2.解决队头阻塞
3.自定义流量控制
4.改进的拥塞控制

QUIC的优点

通过减少往返次数，以缩短连接建立时间，QUIC只需要一次往返就能建立HTTPS连接

独立的数据流避免阻塞问题

改进的拥塞控制
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法

FEC前向纠正拥塞控制
FEC是Forward Error Correction前向错误纠正的意思，就是通过多发一些冗余的包，当有些包丢失时，可以通过冗余的包恢复出来，而不用重传。这个算法在多媒体网关拥塞控制有重要的地位。QUIC的FEC是使用的XOR的方式，即发N + 1个包，多发一个冗余的包，在正常数据的N个包里面任意一个包丢了，可以通过这个冗余的包恢复出来，使用异或可以做到

切换网络操持连接
经常会有从4G切换到wifi网络或者是从wifi切换到4G网络的场景，由于网络的IP变了，导致需要重新建立连接，而QUIC使用一个ID来标志连接，即使切换网络也可以使用之前的建立连接的数据如交换的密钥，而不用再重新HTTPS握手，不过切换的过程可能会导致有些包丢了，需要利用FEC恢复或者重传。

更安全的传输协议
TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。

这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。

QUIC面临的挑战

1.路由封杀UDP 443端口（这正是QUIC 部署的端口）

2.UDP包过多，由于QS限定，会被服务商误认为是攻击，UDP包被丢弃

3.无论是路由器还是防火墙目前对QUIC都还没有做好准备。

应用场景

弱网环境下也可以流畅访问

延时从2s降到800ms

真正的即时通信，网络游戏物联网

HTTP和TCP的区别，TCP是传输层，http是应用层

TCP是传输层协议，http是应用层协议

http是要基于TCP连接基础上的，

简单的说，TCP就是单纯建立连接，不涉及任何我们需要请求的实际数据，简单的传输。

http是用来收发数据，涉及到实际应用上来的。

TCP是底层通讯协议，定义的是数据传输和连接方式的规范
HTTP是应用层协议，定义的是传输数据的内容的规范
HTTP协议中的数据是利用TCP协议传输的，所以支持HTTP也就一定支持TCP

HTTP支持的是www服务
而TCP/IP是协议
它是Internet国际互联网络的基础。TCP/IP是网络中使用的基本的通信协议。
TCP/IP实际上是一组协议，它包括上百个各种功能的协议，如：远程登录、文件传输和电子邮件等，而TCP协议和IP协议是保证数据完整传输的两个基本的重要协议。通常说TCP/IP是Internet协议族，而不单单是TCP和IP。

TCP/IP

●➢HTTP是个应用层协议。
●➢HTTP无需操心网络通信的具体细节;它把联网的细节都交给了通用、可靠的因特网传输协议TCP/IP。
●➢只要建立了TCP连接，客户端和服务器之间的报文交换就不会丢失、不会被破坏，也不会在接收时出现错序了。
●TCP提供了:
➢无差错的数据传输; .
➢按序传输(数据总是会按照发送的顺序到达);
➢未分段的数据流(可以在任意时刻以任意尺寸将数据发送出去)。

TCP/IP四层模型+OSI七层模型（含每一层作用分析）

应用层:决定向用户提供应用服务时通信的活动，
- FTP, DNS, http协议——对tcp 的又一层封装提供用户程序接口
传输层:提供处于网络连接中的两台计算机之间的数据传输
- tcp udp——socket编程就是在传输层，提供传输顺序信息与响应
网络层:用来处理在网络上流动的数据包，规定通过怎样的传输路线到达对方计算机并把数据包传输给
对方
- ip 提供数据通过的路由
数据链路层:进行数据打包与解包，形成信息帧
物理层:实现计算机系统与网络间的物理连接

OSI（Open System Interconnect），即开放式系统互联。

OSI定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层），

每一层实现各自的功能和协议，并完成与相邻层的接口通信。

OSI的服务定义详细说明了各层所提供的服务。某一层的服务就是该层及其下各层的一种能力，它通过接口提供给更高一层。各层所提供的服务与这些服务是怎么实现的无关。

<1> 应用层

OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

<2> 表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

表示层的基本作用就是对数据格式进行编译，对收到或发出的数据根据应用层的特征进行处理，如处理为文字、图片、音频、视频、文档等，还可以对压缩文件进行解压缩、对加密文件进行解密等。

只有在表示层将数据处理完成后，才能将转格式编译后的数据呈现在应用程序中，让用户能够看懂。

<3> 会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

<4> 传输层

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。

<5> 网络层

本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。

<6> 数据链路层

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。

数据链路层又分为2个子层：逻辑链路控制子层（LLC）和媒体访问控制子层（MAC）。

MAC子层处理CSMA/CD算法、数据出错校验、成帧等；LLC子层定义了一些字段使上次协议能共享数据链路层。在实际使用中，LLC子层并非必需的。

<7> 物理层

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

TCP连接是通过4个值来识别的:源IP 地址、源端口号、目的IP地址、目的端口号

TCP连接是通过4个值来识别的:
源IP地址、源端口号、目的IP地址、目的端口号
➢有些连接共享了相同的目的端口号(C和D都使用目的端口号80)。
有些连接使用了相同的源IP地址(B和C)。
➢有些使用了相同的目的IP地址(A和B, C和D)。
➢但没有两个不同连接所有的4个值都-样。

三次握手、四次挥手（含TCP连接状态

三次握手

LISTENING

1.客户端发送syn0给服务器，SYN_SENT (客户端状态)
2.服务器收到syn0，回复syn1,ack(syn0+1) SYN_RECEIVED (服务端状态)
3.客户端收到syn1，回复ack(syn1+1) ESTABLISHED
四次挥手(客户端主动发起连接关闭请求)
1.客户端发送fin，表示要关闭连接；自己进入终止等待1状态（FIN-WAIT-1）
2.服务端收到fin,回复ack,表示自己进入了关闭等待状态（CLOSE-WAIT）；客户端进入终止等待2状态（FIN-WAIT-2）；服务端此时还可以发送未发送的数据，客户端还可以接收数据。
3.待服务端发送完数据之后，回复fin，进入最后确认阶段
4.客户端收到之后回复ack包，进入超时等待状态（TIME-WAIT），经过超时时间后关闭连接，而服务端收到ACK包后，立即关闭连接（CLOSED）

状态迁移过程：

a、客户端：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

b、服务端：CLOSED->LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE

三次握手连接阶段,最后一次ACK包丢失会进入什么样的一个状态

由于server端发送syn_ack报文后进入SYN_RCVD状态，就会启动tcp重传计时器，超时时就会重新发送syn_ack报文，总共发送 net.ipv4.tcp_synack_retries次；如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。

客户端在没有收到重传的syn_ack之前，Client 向 server端发送数据，由于server端的状态为SYN_RCVD状态，而不是ESTABLISHED状态，Server端将以 RST包响应，客户端方能感知服务器未收到ack报文。

为什么要time wait？为什么是2MSL

（为什么客户端需要等待超时时间，这是为了保证对方已收到ACK包，因为假设客户端发送完最后一包ACK包后就释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在最后确认状态；如果客户端发送最后一包ACK包后，等待一段时间，这时服务端因为没有收到ACK包，会重发FIN包，客户端会响应这个FIN包，重发ACK包并刷新超时时间；也是为了保证在不可靠的网络链路中，进行可靠的连接断开确认。

最后一个ack是一个确认报文，对方收到之后就正常关闭连接。自己则等待2msl，如果对方正常关闭，则自己之后正常关闭。MSL指的是任何IP数据报能够在因特网上存活的最长时间，所以来回是2MSL。

MSL指的是任何IP数据报能够在因特网上存活的最长时间。假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL。

为什么连接的时候是三次握手，关闭的时候却是四次挥手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

为什么用三次握手，而不是四次
本来握手应该和挥手一样都是需要确认两个方向都能联通的，本来模型应该是：
1.客户端发送syn0给服务器
2.服务器收到syn0，回复ack(syn0+1)
3.服务器发送syn1
3.客户端收到syn1，回复ack(syn1+1)
因为tcp是全双工的，上边的四部确认了数据在两个方向上都是可以正确到达的，但是2，3步没有没有上下的联系，可以将其合并，加快握手效率，所有就变成了3步握手。

TCP，四次挥手如果改为三次怎么样？
答：最后的确认报文可能丢失，如果丢失了，对方无法收到确认关闭连接的报文，那么就无法关闭连接。

为什么不能用两次握手进行连接？

假设采用两次握手建立连接，客户端向服务端发送了一个SYN包来请求建立连接；

因为某些未知的原因，并没有到达服务器，在中间某个网络节点产生了滞留；

为了建立连接客户端会重发SYN包，这次的数据包正常送达，服务端回复SYN+ACK之后建立起了连接；

但是第一包数据阻塞的网络节点突然恢复，第一包SYN包又送达到服务端，这时服务端会误认为是客户端又发起了一个新的连接，从而在两次握手之后进入等待数据状态。

服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP怎么保证可靠性

TCP协议保证数据传输可靠性的方式主要有：

校验和
序列号
确认应答
超时重传
连接管理
流量控制
拥塞控制

（1）校验和

发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。

（2）确认应答、序列号、超时重传

TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，表示已经收到该数据段，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

如果发送方迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。

（3）通过三次握手与四次挥手的过程保证可靠的连接。

（4）流量控制

接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的接收缓冲区很快的填充满了。

此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。

而TCP会根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

如何控制：在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

（5）拥塞控制

TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。

所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。

如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以TCP在为了防止这种情况而进行了拥塞控制。

慢启动：定义拥塞窗口，一开始将该窗口大小设为1，之后每次收到确认应答（经过一个rtt），将拥塞窗口大小*2。
拥塞避免：设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加（每次确认应答/每个rtt，拥塞窗口大小+1），以此来避免拥塞。

将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗口大小设为初值1，然后重新进入慢启动过程。

快速重传：在遇到3次重复确认应答（高速重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。

然后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3的大小。

这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的过程，网络不会轻易的发生瘫痪。

tcp和udp区别

相同点
UDP协议和TCP协议都是传输层协议。TCP/UDP——传输层——在程序之间传输数据

tcp和udp区别

1）连接——tcp是面向连接的，而udp面向数据报，是无连接就发送数据的

TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接。

UDP无连接。

2）服务对象，通信的双方数量不同

TCP之间仅支持单播（一对一）。TCP是点对点的两点间服务，即一条TCP连接只能有两个端点；

UDP支持单播，多播，广播（一对一，一对多，一对全，多对一，多对多的交互通信）。

3）可靠性——tcp传输时是可靠的，udp传输时是不可靠的

TCP：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制

TCP是可靠交付：无差错，不丢失，不重复，按序到达。tcp的确认重传机制

UDP是尽最大努力交付，不保证可靠交付。udp相比之下容易丢包，报文乱序。

4）TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。

5）拥塞控制，流量控制——以前tcp有个拥塞控制，udp没有

TCP有拥塞控制和流量控制保证数据传输的安全性。

UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。（对实时应用很有用，如IP电话，实时视频会议等）

6）报文长度

TCP是动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的。

UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。

首部开销——首部大小不一样

TCP首部开销大，首部20个字节。（报文头部还有序号、确认序号、窗口、标志等（除了UDP也有的）

UDP首部开销小，8字节。（源端口，目的端口，数据长度，校验和）

8）TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

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

UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

TCP和UDP适用场景

TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。

因此在选用具体协议通信时，应该根据通信数据的要求而决定。

若要保证通信数据完整性，对准确性要求高或者要求有连接，则应该选用TCP 协议
- 比如传输文件、发送邮件、浏览网页等
- SMTP：电子邮件、TELNET：远程终端接入、HTTP、HTTPs：万维网、FTP：文件传输
若要保证通信实时性，要求效率，则使用 UDP 协议（如等）。
- 比如域名查询、视频传输、实时通信\语音通话、视频直播等
- DNS：域名转换、TFTP：文件传输、SNMP：网络管理、NFS：远程文件服务器

长连接与短连接的区别（HTTP 1.1相对于1.0最重要的新特性就是引入了长连接

长连接，也叫持久连接，在TCP层握手成功后，不立即断开连接，并在此连接的基础上进行多次消息交互，直至连接的任意一方（客户端OR服务端）主动断开连接，此过程称为一次完整的长连接。

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。

为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

HTTP 1.1相对于1.0最重要的新特性就是引入了长连接。

短连接，顾名思义，与长连接的区别就是，客户端收到服务端的响应后，立刻发送FIN消息，主动释放连接。也有服务端主动断连的情况，凡是在一次消息交互（发请求-收响应）之后立刻断开连接的情况都称为短连接。
注：短连接是建立在TCP协议上的，有完整的握手挥手流程，区别于UDP协议。

什么时候用长连接，短连接？

1、需要频繁交互的场景使用长连接，如即时通信工具（微信/QQ，QQ也有UDP），相反则使用短连接，比如普通的web网站，只有当浏览器发起请求时才会建立连接，服务器返回相应后，连接立即断开。
2、维持长连接会有一定的系统开销，用户量少不容易看出系统瓶颈，一旦用户量上去了，就很有可能把服务器资源（内存/CPU/网卡）耗尽，所以使用需谨慎。

数据链路层靠什么地址寻址？

Socket套接字

“一切皆Socket!”话虽些许夸张，但是事实也是，现在的网络编程几乎都是用的socket。

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。

什么是套接字：socket是一套用于不同主机间通信的API，它工作在我们的TCP/IP协议栈之上，要通过socket与不同主机建立通信，我们只需要指定主机的IP地址，和一个端口号。IP地址用于唯一标识你的网络设备，端口主要用于区分主机上的不同应用。

网络层的“ip地址”可以唯一标识网络中的主机，而传输层的“协议+端口”可以唯一标识主机中的应用程序（进程）。这样利用三元组（ip地址，协议，端口）就可以标识网络的进程了，网络中的进程通信就可以利用这个标志与其它进程进行交互。

和大多数语言一样,Python支持面向连接和无连接，实现接口功能与步骤也大致相同。

面向连接即需要先连接然后通讯，面向连接主要协议就是传输控制协议(tcp),要创建tcp套接字时需要
指定套接字类型为SOCK _STRAM,表达了他作为流套接字的特点。
无连接，顾名思义无需建立连接就可以进行通讯，这时数据到达顺序、可靠性就无法保证了。实现这种
连接的协议就是用户数据包协议(udp) 。创建UDP时需要指定套接字类型为SOCK _DGRAM。

#基于TCP
#服务端
import socket

# 调用socket中的socket()来创建一个socket s
# with是python中的一个语法糖,代表当代码离开with块的时候,自动调用s.close()来销毁这个socket.
# 指定两个参数，第一个参数AF_INET代表我们使用的是IPv4的地址家族(address family)
# 第二个参数，SOCK_ STREAM代表我们使用的是TCP协议,这里的STREAM也正是代表TCP是个“流式”协议
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind(("0.0.0.0", 1234))  # 绑定IP地址、端口等信息到socket上
    # 网卡我们可以通过IP地址指定,设置为"0.0.0.0"代表你主机上的任意网卡都可以使用这个socket进行通信

    s.listen()  # 对端口进行监听(listen)
    c, addr = s.accept()  # 接收客户端上来的连接，用函数accept(),并返回一个新的socket c,以及客户端的IP地址
    # 注意这个c是一个与之前s不同的socket,socket s主要用于监听,而socket c则用于与连接的客户端进行通信
    with c:
        print(addr, "connected.")  # 打印客户端的IP地址
        while True:  # 这个循环会一直调用recv() 接收客户端传来的信息
            data = c.recv(1024)  # 这里的1024代表一次性接受数据的最大长度,1024个字节
            if not data:
                break
            c.sendall(data)  # 只要数据不为空，就回传给客户端

#客户端
import socket
#创建一个socket, 用函数socket()
with socket.socket(socket.AF_INET,socket.SOCK_STREAM) as s:
    s.connect(("127.0.0.1",1234))#传入服务器的IP地址和端口号,连接服务器，用函数connect()
    s.sendall(b"Hello,Ross")#调用sendall()发送一条消息给服务器,参数是一个字节序列,并不是字符串，不要忘记b
    data=s.recv(1024)#调用recv()接受服务器的消息
    print("Received:",repr(data))
    
多线程解决：
selectors高级I/O复用库
async异步I/O

先从服务器端说起。服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。

什么是HttpOnly & 跨站脚本攻击XSS

**HttpOnly**是加在cookies上的一个标识，用于告诉浏览器不要向客户端脚本（document.cookie或其他）暴露cookie。

如果cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击来窃取cookie内容，这样就增加了cookie的安全性。

HttpOnly背后的相关议题是：当网站存在跨站脚本攻击（XSS）漏洞时,黑客通过执行脚本获得cookie时被阻止，从而在根本上杜绝这种类型的攻击。

当你在cookie上设置HttpOnly标识后，浏览器就会知会到这是特殊的cookie,只能由服务器检索到，所有来自客户端脚本的访问都会被禁止。当然也有前提：使用新版的浏览器。

语法如下：

1	Set-Cookie: Name=Value; expires=Wednesday, 01-May-2014 12:45:10 GMT; HttpOnly

在上面的HTTP请求头中，HttpOnly知会浏览器在保存cookie，但不要向客户端脚本开放访问权限。

另外还有一个安全标识可以强制浏览器发送cookie的时候采用安全通道，比如HTTPS,可以防止被监听。尤其是在HTTPS连接被一些工具（比如SSLStrip等）降级到HTTP。
语法为：

1	Set-Cookie: Name=Value; expires=Wednesday, 01-May-2014 12:45:10 GMT; Secure

在这个HTTP头信息中，Secure标识知会浏览器使用安全的加密通道发送cookie。

**XSS是跨站脚本攻击(Cross Site Scripting)**。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站(流量劫持)等。

举个例子：窃取网页浏览中的cookie值

在网页浏览中我们常常涉及到用户登录，登录完毕之后服务端会返回一个cookie值。这个cookie值相当于一个令牌，拿着这张令牌就等同于证明了你是某个用户。

如果你的cookie值被窃取，那么攻击者很可能能够直接利用你的这张令牌不用密码就登录你的账户。如果想要通过script脚本获得当前页面的cookie值，通常会用到document.cookie。

试想下如果像空间说说中能够写入xss攻击语句，那岂不是看了你说说的人的号你都可以登录（不过某些厂商的cookie有其他验证措施如：Http-Only保证同一cookie不能被滥用）

Web 安全性测试之跨站脚本攻击测试https://zhuanlan.zhihu.com/p/62725624

iPv6 的 128 位地址通常写成 8 组，每组由4个十六进制数组成

ipv4是32位，分四组，每组由3个十进制数组成，[0-255]

负载均衡

为了避免单机性能瓶颈与解决单点故障的隐患，部署多个服务器，如何选择？选择哪台机器来连接的工作最好放在 server 中，具体怎么做呢，在架构设计中有个经典的共识：没有什么是加一层解决不了的，如果有那就再加一层，所以我们在 server 端再加一层，将其命名为（Load Balance，负载均衡）

由 LB统一接收 client 的请求，然后再由它来决定具体与哪一个 server 通信，一般业界普遍使用 Nginx 作为 LB

Nginx 是七层（即应用层）负载均衡器 ，这意味着如果它要转发流量首先得和 client 建立一个 TCP 连接，并且转发的时候也要与转发到的上游 server 建立一个 TCP 连接，而我们知道建立 TCP 连接其实是需要耗费内存（TCP Socket，接收/发送缓存区等需要占用内存）的，客户端和上游服务器要发送数据都需要先发送暂存到到 Nginx 再经由另一端的 TCP 连接传给对方。

所以 Nginx 的负载能力受限于机器I/O，CPU内存等一系列配置，一旦连接很多（比如达到百万）的话，Nginx 抗负载能力就会急遽下降。

经过分析可知 Nginx 的负载能力较差主要是因为它是七层负载均衡器必须要在上下游分别建立两个 TCP 所致，那么是否能设计一个类似路由器那样的只负载转发包但不需要建立连接的负载均衡器呢，这样由于不需要建立连接，只负责转发包，不需要维护额外的 TCP 连接，它的负载能力必然大大提升，于是四层（传输层）负载均衡器 LVS 就诞生了，简单对比下两者的区别

LVS 只是单纯地转发包，不需要和上下游建立连接即可转发包，相比于 Nginx 它的抗负载能力强、性能高，能达到 F5 硬件的 60%；对内存和cpu资源消耗比较低

四层负载均衡器是如何工作的呢
负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过负载均衡算法选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器 IP ），直接转发给该服务器。TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

面试QA整理(1)——计算机网络

http协议

请你来说一说http协议

HTTP工作流程

HTTP特点

HTTP的缺点

报文

HTTP常见的请求头里有什么内容？

HTTP常见的响应头里有什么内容？

什么是Cookie？Cookie用来干什么的？

cookie & session的用处？他们的区别和联系。cookie为什么不安全

HTTP请求命令，http有哪些请求方式，HTTP方法

☆GET和POST的区别

get和post在哪里传参

☆get的幂等性由什么保证？（安全和幂等

☆常见响应状态码

浏览器输入一个URL之后，网络各层发生了什么？（输入url涉及哪些协议、DNS过程

理解URL，以及URL的组成部分

☆http和https的区别

☆ssl具体握手过程（https流程，具体是怎么连接的）https是如何实现安全的

https如何验证证书

https为什么要先非对称再对称

客户端在使用HTTPS方式与Web服务器通信时的步骤

HTTPS优点和缺点

SSL与TLS

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

如何利用UDP实现可靠传输（基于 UDP 的 QUIC 协议）

HTTP和TCP的区别，TCP是传输层，http是应用层

TCP/IP

TCP/IP四层模型+OSI七层模型（含每一层作用分析）

TCP连接是通过4个值来识别的:源IP 地址、源端口号、目的IP地址、目的端口号

三次握手、四次挥手（含TCP连接状态

TCP怎么保证可靠性

tcp和udp区别

TCP和UDP适用场景

长连接与短连接的区别（HTTP 1.1相对于1.0最重要的新特性就是引入了长连接

数据链路层靠什么地址寻址？

Socket套接字

什么是HttpOnly & 跨站脚本攻击XSS

iPv6 的 128 位地址通常写成 8 组，每组由4个十六进制数组成

负载均衡