网络相关总结

一、OSI体系结构各层协议

物理层：比特
数据链路层：帧
网络层：数据报
运输层：报文段/用户数据报
应用层：报文

二、HTTP 与 HTTPS

1、HTTPS协议需要到CA申请证书，需要一定费用
2、HTTP信息是明文传输，HTTPS是具有安全性的SSL加密传输协议
3、HTTPS和HTTP使用的是完全不同的连接方式，前者端口443，后者80
4、HTTP连接简单，是无状态的，HTTPS比HTTP安全。无状态是指两次连接通信之间是没有任何联系的，每次都是一个新的连接，服务端不会记录前后的请求信息。

500：服务器内部错误。
501：服务器不具备完成请求的功能。
502：Bad Gateway错误。
503：服务器目前无法使用。
504： Bad Gateway timeout 网关超时。

三、TCP报文和HTTP报文格式

TCP报文

HTTP报文
请求报文包含三部分：
1、请求行：包含请求方法、URI、HTTP版本信息
2、请求首部字段
3、请求内容实体
响应报文包含三部分：
1、状态行：包含HTTP版本、状态码、状态码的原因短语
2、响应首部字段
3、响应内容实体

四、HTTP1.1新特性

1、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
2、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
3、断点续传原理
HTTP1.1协议中定义了断点续传相关的HTTP头 Range和Content-Range字段，一个最简单的断点续传实现大概如下：
1、客户端下载一个1024K的文件，已经下载了其中512K
2、网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：Range:bytes=512000- 这个头通知服务端从文件的512K位置开始传输文件
3、服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：Content-Range:bytes 512000-/1024000，并且此时服务端返回的HTTP状态码应该是206，而不是200。

现实中，如果在发起续传请求时，URL对应的内容发生了变化，解决方式为：Last-Modified来标识文件的最后修改时间。

五、URI与URL

URI是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。
URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

六、常用的HTTP方法

GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

七、HTTPS工作原理

1、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
2、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）；
3、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
4、发送给服务端，此时只有服务端（RSA私钥）能解密。
5、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

八、cookie和session

1、cookie存放在客户浏览器，session存放在服务器
2、cookie不安全，其他人可以分析本地的cookie进行cookie欺骗
3、session会在一定时间内保存在服务器上，访问增多会占用服务器性能
4、单个cookie保存的数据不能超过4K，很多浏览器限制一个站点最多保存20个cookie
5、登录信息等重要信息存放为session，其他信息放在cookie

九、GET和POST区别

1、GET请求数据会暴露在地址栏中，POST请求不会
2、GET请求传输数据会受URL长度限制，POST不会
3、POST安全性比GET高
4、GET效率比POST高

十、三次握手、四次挥手

三次握手

1、TCP服务器进程先创建传输控制块TCB，此时服务器就进入了 LISTEN（监听）状态
2、TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。
3、TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。
4、TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，自己的序列号是 x+1.
5、此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

四次挥手

1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u，此时客户端进入FIN-WAIT-1（终止等待1）状态。
2、服务器收到连接释放报文，发出确认报文，ACK=1，确认序号为 u+1，并且带上自己的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。
3、客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最终数据）
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认序号为v+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而自己的序列号是u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。

为什么要三次握手

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。

十一、浏览器访问百度的过程

1、通过DNS服务器解析出IP地址
2、发送TCP3次握手进行连接
3、使用HTTP协议发送请求数据给WEB服务器
4、WEB服务器收到请求后，查询到结果，原路返回给浏览器
5、浏览器接收到数据通过渲染功能显示网页
6、浏览器关闭TCP连接，4次挥手结束，完成整个过程

十二、常见的web攻击及其防御

（一）XSS（跨站脚本攻击）
攻击者在 Web 页面中插入恶意脚本，当用户浏览页面时，促使脚本执行，从而达到攻击目的
解决方式：
1、从客户端和服务器端双重验证所有的输入数据，这一般能阻挡大部分注入的脚本
2、对所有的数据进行适当的编码
3、设置 HTTP Header： “X-XSS-Protection: 1”
（二）DDos分布式拒绝服务
发送大量请求，使服务器瘫痪
解决方式：
1、检测技术，检测网站是否正在遭受 DDoS 攻击
2、清洗技术，清洗掉异常流量。
（三）CSRF跨站请求伪造
用户本地存储cookie，攻击者利用用户的cookie进行认证，然后伪造用户发出请求
解决方式：
1、检查标准头部，确认请求是否同源
2、检查 CSRF Token
（四）SQL注入
通过用户输入，拼接成恶意sql，并执行
解决方式：
1、参数化的查询语句可以强制应用开发者首先定义所有的 sql 代码，之后再将每个参数传递给查询语句
2、使用语言自带的存储程序，而不是自己直接操纵数据库
3、验证用户的输入
4、对用户提供的所有的输入都进行编码

十三、其他

1、Robots 协议：网站通过 Robots 协议告诉搜索引擎哪些页面可以抓取，哪些页面不能抓取，但它仅仅是道德层面上的约束
2、现代浏览器会自动添加一些标签，例如。那么在使用xpath时就会出现找不到元素标签的情况。比较好的实践是逐渐缩小范围，观察区域的标签嵌套结构。
3、图片懒加载
这是一种前端技术，缓解服务器压力，给用户更好的体验，他只对屏幕内的图片进行加载，其他的图片使用伪属性隐藏起来，当检测到屏幕要显示时，改变为原生属性，所以可以通过伪属性名获取图片地址。