从输入URL（www.google.com）到页面加载发生了什么？

1.DNS解析（网址 -> IP地址）：DNS缓存：浏览器和操作系统。分级查询：本地DNF服务器，根域名服务器，com顶级域名服务器，google.com域名服务器 
2.TCP连接（三次握手）-> 为什么两次不可以？
3.发送HTTP请求
4.服务器处理请求，并且返回HTTP报文
5.浏览器解析和渲染页面
6.连接结束（四次挥手）-> 为什么三次不可以？

DNS解析流程：

6055764-8ca1c59f8c2da535.png

DNS 解析安全问题

1、DNS 劫持

DNS 劫持.png

一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的本地 DNS 服务器进行篡改，指向黑客自己伪造的本地 DNS 服务器，进而通过控制本地 DNS 服务器的逻辑返回错误的 IP 信息进行域名劫持。另一方面，由于 DNS 解析主要是基于 UDP 协议，除了上述攻击行为外，攻击者还可以监听终端用户的域名解析请求，并在本地 DNS 服务器返回正确结果之前将伪造的 DNS 解析响应传递给终端用户，进而控制终端用户的域名访问行为。

2、缓存污染（DNS 污染）。
我们知道在接收到域名解析请求时，本地 DNS 服务器首先会查找缓存，如果缓存命中就会直接返回缓存结果，不再进行递归 DNS 查询。这时候如果本地 DNS 服务器针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。
3、如何解决 DNS 劫持？
DNS 解析发生在 HTTP 协议之前，DNS 解析和 DNS 劫持和 HTTP 没有关系，DNS 协议使用的是 UDP 协议向服务器的 53 端口进行请求。要想解决 DNS 劫持：

可以使用 HttpDNS 的方案：使用 HTTP 协议向 DNS 服务器的 80 端口进行请求,来规避 DNS 劫持比如：http://119.29.29.29/d?dn=domain&ip=clientIp
在终端上，可以更换 DNS 服务器，不管手机还是电脑，都能手动配置 DNS

三次握手：

第一次握手：客户端 -> 服务端：发送SYN=1（请求建立连接），seq=n（序列号）
第二次握手：服务端 -> 客户端：SYN=1（同意建立连接），服务器收到客户端的seq序列号，它会给它发送ack字段=n+1(序列号加1，确认收到信息)和seq=x（服务端序列号）
第三次握手：客户端 -> 服务端：SYN=0（开始发送信息）,发送ack字段=x+1(序列号加1，确认收到信息)和seq=n+1

第一次握手表示：客户端具有发送信息的能力
第二次握手表示：服务端具有接收信息的能力和发送信息的能力
第三次握手表示：客户端具有接收信息的能力

TCP三次握手过程
第一次握手：主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B，向主机B 请求建立连接，通过这个数据段，主机A告诉主机B 两件事：我想要和你通信；你可以用哪个序列号作为起始数据段来回应我。

第二次握手：主机B 收到主机A的请求后，用一个带有确认应答（ACK）和同步序列号（SYN）标志位的数据段响应主机A，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用那个序列号作为起始数据段来回应我

第三次握手：主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B 的数据段："我已收到回复，我现在要开始传输实际数据了，这样3次握手就完成了，主机A和主机B 就可以传输数据了。

三次握手原因
避免资源被浪费掉。如果在第二步握手时，由于网络延迟导致确认包不能及时到达客户端，那么客户端会认为第一次握手失败，再次发送连接请求，服务端收到后再次发送确认包。在这种情况下，服务端已经创建了两次连接，等待两个客户端发送数据，而实际却只有一个客户端发送数据。

三次握手的特点
没有应用层的数据 ,SYN这个标志位只有在TCP建立连接时才会被置1 ,握手完成后SYN标志位被置0。

四次挥手：

第一次挥手：客户端 -> 服务端：发完了
第二次挥手：服务端 -> 客户端：知道发完了
第三次挥手：服务端 -> 客户端：收完了
第四次挥手：客户端 -> 服务端：知道收完了

第一次:发完了，第二次：知道发完了，第三次:收完了，第四次:知道收完了

TCP建立连接要进行3次握手，而断开连接要进行4次
第一次：当主机A完成数据传输后,将控制位FIN置1，提出停止TCP连接的请求；

第二次：主机B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭,将ACK置1；

第三次：由B 端再提出反方向的关闭请求,将FIN置1 ；

第四次：主机A对主机B的请求进行确认，将ACK置1，双方向的关闭结束.。

由TCP的三次握手和四次断开可以看出，TCP使用面向连接的通信方式，大大提高了数据通信的可靠性，使发送数据端和接收端在数据正式传输前就有了交互，为数据正式传输打下了可靠的基础。

四次挥手原因
由于TCP的连接是全双工，双方都可以主动传输数据，一方的断开需要告知对方，让对方可以相关操作，负责任的表现。

使用TCP协议有：FTP（文件传输协议）、Telnet（远程登录协议）、SMTP（简单邮件传输协议）、POP3（和SMTP相对，用于接收邮件）、HTTP协议等

浏览器解析和渲染页面：

自上而下下载||渲染 css并行图片异步请求下载 js挂起
html -> dom + css -> cssom = render渲染树（不渲染：head，display:none）4.布局 5.绘制

影响一个HTTP网络请求的因素

1.网络波动或者网络延迟；这种情况最常见，导致的原因是由服务器之间网络的连通情况和心跳包的容纳情况决定的
2.跨域请求；这种情况一般出现在做外贸或者金融类的公司，比如，美国的服务器，访问上海的服务器，异地处理，请求需要跨越VPN和国际传输，在加上三次握手协议，再加上国际信息传输的特殊渠道供给和波动，会大大延迟数据的响应时间
3.服务器转发次数过多；比如A服务器给B服务请发起请求，B服务器在转发给C由C处理结果之后在依次返回，最后又A收到结果，请求时效加倍，响应时效加倍，服务的可用率就降低了
4.服务器本身的原因：网卡不够完善（多网卡划分，网卡部分缺失），内存供给不足等等都会导致各种各样的响应慢
5.网段划分不一致：如A服务器10M带宽，B服务器10K带宽（分流），1秒一次的心跳，最终决定响应时间的一定是最慢的那个B，因为B的慢，会拖累整个服务集群交互;再比如阿里云华南地区和华北地区两台服务器之间的交互也没有两台华北地区服务器交互来得快
…
简单说，要想服务器交互的尽可能的快，尽量保证服务器的部署网段尽可能一致，带宽没有短板，尽量减少多次转发和跨域的可能性…

更多原因：HTTP慢的原因和解决方式

HTTP和HTTPS的区别

HTTPS：HTTP -> SSL（加密）/TLS（解密）包括对称加密和非对称加密，公钥和私钥代表非对称加密，只有密钥就是对称加密

1.HTTPS需要CA请求证书（付费的）
2.HTTP传输都是明文传送的可以截获，HTTPS传输都是客户端通过SSL加密，服务端通过TLS解密
3.连接方式，端口不同，HTTP端口80，HTTPS端口443
4.HTTPS防止运营商劫持

证书机制

1.作为服务端的小红，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。
2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端小红。
3.当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰。
4.小灰收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。

参考链接:
https://blog.csdn.net/jiangshangchunjiezi/article/details/88545263

Https单向认证和双向认证
app客户端不需要处理证书就属于单向认证，双向认证app客户端是属要处理证书的。

Get、Post区别

(1). 从功能上讲
GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；

(2). 从REST服务（REST软件架构）角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；

(3). 从请求参数形式上看
GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；
而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中。

(4). 就安全性而言
POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。

(5). 从请求的大小看
GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

参考链接:
https://blog.csdn.net/jiangshangchunjiezi/java/article/details/88546010

Cookie、Session区别

cookie 和session 的区别：

1、存放位置：cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、安全性：cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。

3、性能：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

4、大小限制：单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。Session没有大小限制，理论上只与服务器的内存大小有关；

5、所以个人建议：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

TCP、UDP 区别

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议

TCP的优点
可靠，稳定
TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。

TCP的缺点
慢，效率低，占用系统资源高，易被攻击
TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。

由于TCP存在确认机制和三次握手机制，这些是导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。

TCP应用场景
当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。

在日常生活中，常见使用TCP协议的应用比如：浏览器使用HTTP，Outlook使用POP、SMTP，QQ文件传输等。

UDP协议
UDP 是User Datagram Protocol的简称，中文名是用户数据报协议，是OSI（Open System Interconnection，开放式系统互联）参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。

UDP的优点
快，比TCP稍安全
UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击……

UDP的缺点
不可靠，不稳定
因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。

UDP应用场景
当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。在日常生活中，常见使用UDP协议的应用比如：QQ语音、QQ视频、TFTP等。

Socekt 类似SDK ，就是封装了TCP和 UDP 这些协议的东西，方便程序员调用

说说TCP,UDP和socket,Http之间联系和区别

HTTP 的请求方式

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

image.png

1、GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
4、PUT
向指定资源位置上传其最新内容
5、DELETE
请求服务器删除Request-URL所标识的资源
6、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
8、TRACE
回显服务器收到的请求，主要用于测试或诊断
9、PATCH
是对PUT方法的补充，用来对已知资源进行局部更新。

计算机网络相关知识