[网络协议]计算机网络

整理下吧，为了秋招，只是手头暂时没书，后续一定好好写，写博客有利于自己学习，整理和回顾自己的学习过程

五层网络模型

物理层，数据链路层，网络层，运输层，应用层

从后往前

应用层：

? ? ? ? DNS域名系统：

? ? ? ? ? ? ? ? 每个网址都是https://mp.csdn.net?这样的从后往前是顶级域名，一级，二级。。。

? ? ? ? ? ? ? ? 这样根据域名就可以得到对应IP地址 通过UDP协议运输

简述在网站输入一个URL，返回一个页面的过程，并输出其中使用了那些协议？

根据URL在DNS域名系统中使用迭代查询或递归查询得到IP地址，中间会用到UDP协议，得到IP地址后建立HTTP链接，需要发送一个http请求get数据包，生成一个响应报文，之后对wed页面进行渲染将内容呈现，中间会用到TCP协议，如果是http链接的话还需要进行SSH加密操作，IP地址和MAC地址的转换还会使用ARP和RARP协议

会追问? http和https的区别

如何渲染页面

GET POST区别

详细描述ssl加密过程

TCP和UDP特性区别

TCP如何保证可靠性

TCP三次握手四次挥手

TCP拥塞控制

1.http和https的区别？

http协议传输的报文是以明文形式传输的，https传输的是ssl加密后的报文

https需要浏览器安装对应的根证书（这个后续会提）

使用的端口号不同

https安全性更高，握手延时也更高（tcp三次握手建立连接后还需要ssl三次握手加密），费用也更高（根证书要钱的）

（在网络中用于区别同一个ip地址下的不同进程用的就是端口号，常用的进程有固定的端口号）

追问：简述ssl三次握手的流程

（ssl加密使用的是对称加密和非对称加密联合的方式关于对称加密和非对称加密自行百度了解）

首先客户端以明文形式发送版本信息，加密套件，压缩算法，再给一个随机数

服务端收到后回复用哪个协议，加密套件，压缩算法，自己生成一个随机数给对方（两边都有2个随机数了目前）

然后服务端会给自己的根证书（证明自己不是恶意软件）

（客户端有自己信任的CA（担保人）如果自己的CA不信任这个根证书就会不断去询问自己信任的CA直到找到一个可以担保该浏览器的CA）

验证通过后客户端会生成第二个随机数，然后用根证书中的公钥加密发送给服务端

此时双方都有了三个随机数，然后根据这些随机数算出密钥

之后的通讯都用该密钥加密

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Get和post区别

GET请求在URL中传送的参数是有长度限制的，而POST么有。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

GET产生一个TCP数据包；POST产生两个TCP数据包。

（post流程，先发一个数据包告诉浏览器我要给你发一个post命令，然后再发一个数据包）

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

不同端口通讯协议

UDP协议

特性：尽最大努力交付，无连接，报文流传输（收到什么发什么不切割），支持n：m

不可靠（这里的不可靠不是传输的数据会出现问题，报文首部含有校验码，他的不可靠是指没确认号，超时重传，不能保证数据都到达的不可靠，不是数据内部出错）

TCP协议

特性? 面向连接，可靠传输，字节流传输（切割报文发送） 一对一连接

TCP三次握手

过程? 客户端SYN置1 发送连接请求，服务端收到后SYN置1，ACK置1，前者表示请求连接，后者表示确认收到，可以一起发就一起发了，当然也可以分开发，但是没必要，多发一次还浪费资源，这也就是为什么不是四次握手的原因了，客户端收到后发送ACK置1的确认信号，然后tcp连接完成，最后一次确认如果没发的话，那么游离的第一次请求连接信号发送到服务端就会造成连接，这样会造成资源的浪费

TCP四次挥手

客户端FIN置1 发起断开连接请求自身进入fin_wait1状态，服务端收到该报文后，返回一个ack为1的确认报文，服务端进入time_wait状态，需要发送的数据发送完毕后，发送一个FIN置1的断开请求，客户端收到确认报文后进入fin_wait2状态，然后发送确认报文，自身进入time_wait状态，等待2msl时间(该状态是为了保证服务端收到确认报文)

TCP如何保证可靠性

序列号，确认应答，超时重传，快重传

收到报文后会返回一个确认报文，超时未收到确认报文就会重传该报文，确认报文的序号为想要收到的序列号，如果连续收到三个相同的确认报文那么立刻重传

TCP一个报文一个报文的发送，收到一个确认发下一个实在是太慢了于是就有了

滑动窗口机制

每次发送的是一个窗口的数据，收到一个确认，窗口就前移一个，如果没收到下一个报文的确认就停在原地，后面的确认也不要了

窗口有了，窗口的大小是不是也得随着时间流动，网络速度变化而变化效率更高一点呢？于是就有了拥塞控制

拥塞控制

慢开始? 刚开始窗口大小为1，每次*2直到达到阈值

拥塞避免? 达到阈值后每次+1

快重传 窗口大小达到门限后就会发生超时重传现象，然后连续收到三个确认报文就是快速重传，然后阈值会变为当前的窗口大小的一半，之后会重复慢开始或快开始

快开始 窗口变为阈值大小，每次+1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~