第一章：网络相关
一、HTTP协议
HTTP是什么？
HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
1.浏览器输入url按回车后背后经历了哪些？
在PC浏览器的地址栏输入一串URL，然后按Enter键这个页面渲染出来，这个过程中都发生了什么事?
1）首先，在浏览器地址栏输入url，先解析url，检测url地址是否合法
2）浏览器先查看 浏览器缓存-系统缓存-路由器缓存，如果缓存中有，会直接在屏幕中显示页面内容，若没有，则跳到第三步操作。
浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操系统，获取操作系统的记录（保存最近的DNS查询缓存）；
路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
ISP缓存：若上述均失败，继续向ISP搜索。
3）在发送http请求前，需要域名解析（DNS解析），解析获取相应的IP地址。
4）浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。
5）握手成功后，浏览器向服务器发送http请求，请求数据包。
6）服务器处理收到的请求，将数据返回至浏览器。
7）浏览器收到HTTP响应。
8）浏览器解码响应，如果响应可以缓存，则存入缓存。
9）浏览器发送请求获取嵌入在HTML中的资源（html,css,javascript,图片，音乐......），对于未知类型，会弹出对话框。
10）浏览器发送异步请求。
11）页面全部渲染结束。
2.get和post请求区别
首先，get和post是HTTP协议中的两种发送请求的方法。GET和POST本质上就是TCP链接，并无差别，但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
GET和POST最大的区别在于，GET产生一个TCP数据包，POST产生两个TCP数据包。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）
对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200ok（返回数据）
举个栗子：GET只需要汽车跑一趟就把货送到了，而POST跑两趟，第一趟先去和服务器打个招呼“嗨，我等下要送一批货过来，你们开门迎接我哈”，然后再把货送过去。
GET和POST都有自己的语义，不能随便混用。
在网络不好的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
------标准答案------（但这一般不是面试官想听的 回答上面的即可）
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
3.cookies机制和session机制的区别
cookies数据保存在客户端，session数据保存在服务器端；
cookies可以减轻服务器压力，但是不安全，容易进行cookies欺骗；
session较安全，但占用服务器资源。
4.HTTP状态码
·200 请求已成功 请求所希望的响应头或数据体将随此响应返回。
·201 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其URI已经随Location头信息返回
·202 服务器已接受请求，但尚未处理
·301 (永久移动) 请求的网页已永久移动到新位置。服务器返回此响应（对GET或HEAD请求的响应）时，会自动将请求者转到新位置，
·302 (临时移动) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
·303 (查看其他位置) 请求者应当对不同的位置使用单独的GET请求来检索响应时，服务器返回此代码。
·304 (未修改) 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
·305 (使用代理) 请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
·307 (临时重定向) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
·401 当前请求需要用户验证。如果当前请求已经包含了Authroization证书，那么401响应代表着服务器验证已经拒绝了那些证书
·403 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而这个请求也不应该被重复提交
·404 请求失败，请求所希望得到的资源未被在服务器上发现
·500 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现，
·501 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
·502 作为网关或者代理工作的服务器尝试这行请求时，从上游服务器接收到无效的响应
·503 由于临时的服务器维护或者过载，服务器当前无法处理请求，这个状况是临时的，并且将在一段时间以后恢复。
5.http协议有哪几种请求方式
GET,POST,HEAD,OPTIONS,PUT,DELETE,TRACE,CONNECT方法
6.http和https的区别
HTTP协议传输的数据是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
总的来说：HTTPS = SSL+HTTP
1.https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2.http是超文本传输协议，信息是明文传输，https则是具有安全性的ss加密传输协议。
3.http和https使用的是完全不同的连接方式，用的端口也不一样，前者是83，后者是443。
（这个只是默认端口不一样，实际上端口是可以改的）
4.http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
报文
7.HTTP请求报文与响应报文格式
请求报文包含三部分：
a.请求行：包含请求方法、URI、HTTP版本信息
b.请求头部(headers)字段
c.请求内容实体(body)
响应报文包含三部分:
a.状态行：包含HTTP版本、状态码、状态码的原因短语
b.响应头部(headers)字段
c.响应内容(body)实体
post请求body
8.常见的POST提交数据方式
application/x-www-form-urlencode
multipart/form-data
application/json-------Android常用
text/xml----------------- HTML5常用
DNS
9.什么是DNS
域名解析服务。将主机名转换为IP地址。如将http://www.cnblogs.com/主机名转换为IP地址：211.137.51.78
无状态
10.什么是Http协议无状态协议？怎么解决Http协议无状态协议
1）无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
2）无状态协议解决办法：通过 1.Cookie 2. 通过Session会话保存。
二、TCP/IP协议
1.含义
TCP
(Transmission Control Protocol传输控制协议) 是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议(UDP)是同一层内；另一个重要的传输协议。
IP
网络之间互连的协议(IP)是Internet Protocol的外语缩写
网络之间互连的协议也就是为计算机网络相互连接进行通信而设计的协议
如今的IP网络使用32位地址，以点分十进制表示，如192.168.0.1
地址格式为：IP地址=网络地址+主机地址 或 IP地址=网络地址+子网地址+主机地址
TCP/IP基础知识
TCP/IP全称是Transmission Control Protocol/Internet Protocol。 IP地址共32位，4字节。
IP地址分为两部分：网络标识和主机标识。
A类IP地址：第一段为网络标识，剩下三段为主机标识。网络地址最高位必须为零。网络标识长度为7位，主机标识长度为24位。A类网络的主机数最多可以达到1600多台。
B类IP地址：第一、二段为网络标识，第三、四段为主机标识，网络地址最高位必须为10。网络标识长度为14位，主机标识长度为16位。每个网络最多能容纳6万多台主机。
C类IP地址：前三段为网络标识，剩下一段为主机标识，网络地址最高位必须为110。网络标识长度为21位，主机标识长度为8位。每个网络最多容纳254台主机。
子网掩码也是32位的一个IP地址，它的用途是识别本网络内的计算机。两台不同主机的IP地址同时与子网掩码进行AND运算，如果得出结果相同，则说明这两台计算机处于同一个子网内，可以进行直接通信。域名的构成：主机名+机构名+网络名+最高层域名。
TCP和UDP区别是什么
TCP是有连接的，有连接的意思是开始传输实际数据之前TCP的哭护短和服务器端必须通过三次握手建立连接，会话结局之后也要结束连接。而UDP是无连接的。
TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
TCP协议所需资源多，TCP首部需20个字节(不算可选项)，UDP首部字段只需8个字节。
TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率。
TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
TCP面向的是字节流的服务，UDP面向的是报文的服务。
男盆友个人理解tcp更安全一些，一般接收邮件用tcp，udp一般用于，直播，短视频，传输流量比较大特点传输速度快，但是不安全，tcp是双向的，我发一个东西，会等你给我回复，你确认收到了，我才会给你发下一个，udp是单向的，我只管发给你，你收没收到，我不关心，所以有时直播会出现卡顿马赛克那用就是这种效果
TCP三次握手
三次握手的本质是确认通信双方收发数据的能力
首先，我让信使运输一份信件给对方，对方收到了，那么他就知道了我的发件能力和他的收件能力是可以的。
于是他给我回信，我若收到了，我便通知我的发件能力和他的接收呢你是可以的，并且他的发件能力和我的接收能力是可以的。
然而此时他还不知道他的发件能力和我的接收能力到底可不可以，于是我最后回馈一次，他若收到了，他便清楚他的发件能力和我的接收能力是可以的。
image.png
ACK：确认序号有效。
FIN：释放一个连接。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
URG：紧急指针（urgent pointer）有效。
-
序列号seq
占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号，序列号seq就是这个报文段中的第一个字节的数据编号。 -
确认号ack
占4个字节，期待收到对方下一个报文段的第一个数据字节的序号，序列号表示报文段携带数据的第一个字节的编号，而确认号指的是期望接受到下一个字节的编号，因此挡墙报文段最后一个字节的编号+1即是确认号。 -
确认ACK
占1个比特位，仅当ACK=1，确认号字段才有效。ACK=0，确认号无效。 -
同步SYN
连接建立时用于同步序号。当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1.因此，SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0. -
终止FIN
用来释放一个连接
第一次握手：客户端要向服务端发起连接请求，首先客户端随机生成一个起始序列号ISN(比如是100)，那客户端向服务端发送的报文段包含SYN标志位(也就是SYN=1),序列号seq=100。
第二次握手：服务端收到客户端发过来的报文后，发现SYN=1，知道这是一个连接请求，于是将客户端的起始序列号100存起来，并且随机生成一个服务端的起始序列号(比如是300)。然后给客户端回复一段报文，回复报文包含SYN和ACK标志(也就是SYN=1,ACK=1)、序列号seq=300、确认号ack=101(客户端发过来的序列号+1)。
第三次握手：客户端收到服务端的回复后发现ACK=1并且ack=101，于是知道服务端已经收到了序列号为100的那段报文；同时发现SYN=1,知道了服务端同意了这次连接，于是就将服务端的序列号300给存下来。然后客户端再回复一段报文给服务端，报文包含ACK标志位(ACK=1)、ack=301(服务端序列号+1)、seq=101(第一次握手时发送报文是占据一个序列号的，所以这次seq就从101开始，需要注意的是不携带数据的ACK报文是不占据序列号的，所以后面第一次正式发送数据时seq还是101)。当服务端收到报文后发现ACK=1并且ack=301，就知道客户端收到序列号为300的报文了，就这样哭护短和服务端通过TCP建立了连接。
四次挥手
四次挥手的目的是关闭一个连接
image.png
比如客户端初始化的序列号是ISA=100，服务端初始化的序列号ISA=300。TCP连接成功后客户端总共发送了1000个字节的数据，服务端在客户端发FIN报文前总共回复了2000个字节的数据。
第一次挥手：当客户端的数据都传输完成后，客户端向服务端发出连接释放报文(当然数据没发完时也可以发送连接释放报文并停止发送数据)，释放连接报文包含FIN标志位(FIN=1）、序列号seq=1101(100+1+1000，其中的1是建立连接时占得一个序列号)。需要注意的是客户端发出FIN报文段后只是不能发数据了，但是还可以正常收数据；另外FIN报文段即使不携带数据也要占据一个序列号。
第二次挥手：服务端收到客户端发的FIN报文后给客户端回复确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=1102(客户端FIN报文序列号1101+1)、序列号seq=2300(300+2000)。此时服务端处于关闭等待状态，而不是立马给客户端发FIN报文，这个状态还要持续一段时间，因为服务端可能还有数据没发完。
第三次挥手：服务端将最后数据(比如50个字节)发送完毕后就向客户端发出连接释放报文，报文包含FIN和ACK标志位(FIN=1,ACK=1)、确认号和第二次挥手一样ack=1102、序列号seq=2350(2300+50)。
第四次挥手：客户端收到服务端发的FIN报文后，向服务端发出确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=2351、序列号seq=1102。注意客户端发出确认报文后不是立马释放TCP连接，而是要经过2MSL(最长报文段寿命的2倍时长)后才释放TCP连接。而服务端一旦收到客户端发出的确认报文就会立马释放TCP连接，所以服务端结束TCP连接的时间要比客户端早一些。
TCP/IP与OSI
image.png
image.png
SYN攻击
在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态。当收到ACK后，服务器转入ESTABLISHED状态。
Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV
一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
但是不能完全防范syn攻击。
一个 TCP 连接上面能发多少个 HTTP 请求
一道经典的面试题是从 URL 在浏览器被被输入到页面展现的过程中发生了什么，大多数回答都是说请求响应之后 DOM 怎么被构建，被绘制出来。但是你有没有想过，收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？
要搞懂这个问题，我们需要先解决下面五个问题：
- 现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？
- 一个 TCP 连接可以对应几个 HTTP 请求？
- 一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？
- 为什么有的时候刷新页面不需要重新建立 SSL 连接？
- 浏览器对同一 Host 建立 TCP 连接到数量有没有限制？
先来谈谈第一个问题：现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？
在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。所以虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免，两张图片是我短时间内两次访问 https://www.github.com 的时间统计：
image.png
头一次访问，有初始化连接和 SSL 开销
image.png
初始化连接和 SSL 开销消失了，说明使用的是同一个 TCP 连接
持久连接：既然维持 TCP 连接好处这么多，HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。
所以第一个问题的答案是：默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接。
第二个问题：一个 TCP 连接可以对应几个 HTTP 请求？
了解了第一个问题之后，其实这个问题已经有了答案，如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。
第三个问题：一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？
HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。
虽然 HTTP/1.1 规范中规定了 Pipelining 来试图解决这个问题，但是这个功能在浏览器中默认是关闭的。
先来看一下 Pipelining 是什么，RFC 2616 中规定了：
A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。
至于标准为什么这么设定，我们可以大概推测一个原因：由于 HTTP/1.1 是个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。比如你向服务器发送了两个请求 GET /query?q=A 和 GET /query?q=B，服务器返回了两个结果，浏览器是没有办法根据响应结果来判断响应对应于哪一个请求的。
HTTP2 提供了 Multiplexing 多路传输特性，可以在一个 TCP 连接中同时完成多个 HTTP 请求。至于 Multiplexing 具体怎么实现的就是另一个问题了。我们可以看一下使用 HTTP2 的效果。
image.png
绿色是发起请求到请求返回的等待时间，蓝色是响应的下载时间，可以看到都是在同一个 Connection，并行完成的
所以这个问题也有了答案：在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
那么在 HTTP/1.1 时代，浏览器是如何提高页面加载效率的呢？主要有下面两点：
- 维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求。
- 和服务器建立多个 TCP 连接。
第四个问题：为什么有的时候刷新页面不需要重新建立 SSL 连接？
在第一个问题的讨论中已经有答案了，TCP 连接有的时候会被浏览器和服务端维持一段时间。TCP 不需要重新建立，SSL 自然也会用之前的。
第五个问题：浏览器对同一 Host 建立 TCP 连接到数量有没有限制？
假设我们还处在 HTTP/1.1 时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？肯定不能只开一个 TCP 连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个 TCP 连接发 HTTP 请求，那电脑或者服务器都可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 连接吧，你的电脑同意 NAT 也不一定会同意。
所以答案是：有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。
那么回到最开始的问题，收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？
如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。
如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。
由于简书文字受限，新的知识探索请移步下一篇文章哦----数据结构与算法相关
https://www.jianshu.com/p/61024aae8e0e
网友评论