计算机网络_ppp arp区别

1.tcp/ip 5层模型

应用层：为特定应用程序提供数据传输服务. HTTP、DNS、ftp、SMTP

传输层：为进程提供通用数据传输服务。 TCP、UDP

网络层：为主机提供传输服务。 IP、ARP

数据链路层：数据链路层把网络层传下来的分组封装成 帧。

物理层：考虑的是怎样在传输媒体上传输数据 比特流 。

比如：一条网线拉到了实验室，两台电脑用网线连接，两人用实验室的电脑QQ发送信息。

拉到实验室的网线为：物理层。QQ信息数据在网线上的传播为链路层，不同电脑之间的查找，地址为IP(防止找错人)，通过IP查找到以后建立TCP或者UDP连接。登录QQ为应用层。

tcp/ip四层协议
网络接口层，网络层，运输层，应用层

2.TCP/UDP的区别

（1）TCP面向连接 （建立连接需要三次握手），UDP面向非连接即发送数据前不需要建立链接。

（2）TCP提供可靠的服务，UDP无法保证
（3）TCP数据传输慢，UDP数据传输快

3. TCP三次握手（谁向谁发送的，作用，什么包，叫什么）

TCP协议在建立连接的时候，需要经历三次握手的过程，

第一次握手：是由客户端向服务器端发起的，这是用来去发起一个连接建立的请求，那么这个报文中的SYN位会被标记位：1，所以我们常把它叫做一个SYN包。

第二次握手：是由服务器向客服端发起的，是来确认服务器的一个请求连接的，这个报文中的ACK位和SYN都被标记位1，所以经常被叫做SYN-ACK报文。

第三次握手：客户端向服务器发送请求，这是对服务器上一个报文的确认报文，这个报文中的一个ACK被标记为：1，所以我们也把他叫做一个ACK包。

例如：
A:在吗？
B:在。
A:知道了。
下面就该说正事了。

4.TCP四次挥手

TCP当他完成发送数据以后，就会尝试断开连接，此时经历四次挥手过程，

第一次挥手：是客服端向服务器发送的，这个时候客服端已经完成了数据发送，会发起一个包，去进行一个连接断开的请求，那么这个报文中FIN位为1，所以我们也把他叫做一个FIN包。

第二次挥手：是服务器发送给客服端的，这个报文是用来确认上一个客服端用来断开连接请求的一个报文，所以他是一个ACK报文。

第三次挥手：是服务器发送给客户短的，那么这个时候如果服务器的数据也发送完毕的话，他也会向客服端发起一个断开连接的请求，那么这个报文中的FIN位同样也被标记为1，所以这也是一个FIN包。

第四次挥手是客户端发给服务器的，是用来确认服务器上一个断开连接的一个请求报文，所以这次挥手也是一个ACK报文。

注意：TCP全双工通信

为什么TCP连接的时候是3次？

三次握手主要有两个目的：信息对等和防止超时。
从信息对等的角度看：在第3次握手后，服务器才能确认自己的发报能力和对方的收报能力是正常的。
从防止超时来看：连接三次握手也是防止出现请求超时导致胀读连接，网络报文的生存时间往往会超过TCP请求超时时间。如果两次握手都可以创建连接，超时报文过来以后，服务器以为要建立连接，就会往客服端发送确认连接，但是此时发送方并不处于等待状态，服务器会一直等待下去。如果采用三次握手，服务器长时间没有收到确认消息，最终超时导致连接创建失败，因而不会出现胀读。

关闭的时候却是4次？

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能#一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

如果没有第四次挥手，服务器接受不到确认，就会一直等待，不关闭服务器。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

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

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

5.信号传输有哪几种方式

（1）单工通信：只能有一个方向 的通信而没有反方向的交互。电视机
（2）半双工通信：通信的双方都可以发送信息,但不能双方同时发送。 对讲机
（3）全双工通信：双方可以同时发送和接收信息。 电话

6.虚电路和数据报的区别

虚电路技术
数据在传输之前，建立一条虚拟的电路（比如数据走那个路由器是固定的）可靠由网络保证 ，它适合用于两端之间长时间的数据交换，分组按顺序到达。当有一个路由出现问题，所有经过该结点的虚电路不能工作。

优点：可靠、保持顺序；

缺点：*如有故障，则经过故障点数据全部丢失。

数据报
把数据分组，每个分组被称为一个数据报，在目的需要重新组装报文，可靠性由用户主机保证。

优点：路由器节点有问题，可以绕过。

缺点：不能保证顺序到达，丢失不能立即知晓。

7.ipv4和ipv6的区别

8.从输入网址到网页显示的过程是什么？（重要）

(1)在浏览器中输入网址 URL

(2) 发送到 DNS (域名服务器)获得域名对应的WEB服务器的 IP地址。

(3)客户端浏览器与WEB服务器建立 TCP(传输控制协议)连接。

(4)客户端浏览器向对应IP地址的WEB服务器发送相应的 HTTP或HTTPS请求。

(5) WEB服务器响应请求，返回指定的URL数据或错误信息；如果设定重定向该服务器没有内容，转到其他服务器，则重定向到新的URL地址。

(6) 客户端浏览器下载数据， 解析HTML源文件 ，解析的过程中实现对页面的排版，解析完成后，在浏览器中显示基础的页面。

(7)分析页面中的超链接，显示在当前页面，重复以上过程直至没有超链接需要发送，完成页面的全部显示。

9.滑动窗口

TCP采用以字节为单位的滑动窗口：
我们采用单方向的传输为例，主机A发送数据，主机B给出确认。主机B给主机A发送的字段为rwnd=20,确认字段为30（主机B下一个字段期望收到的序号为30），序号29已经收到了，主机A根据这两个字段值，就可以构造发送窗口（不考虑拥塞窗口），主机B没有发出确认字段的时候，主机A中滑动窗口值保留，防止超时重传时候使用。主机B只能对收到的按序最高字节进行确认。

10.HTTP发展历程

HTTP 0.9

只是一个草案，纯文本格式。蒂姆.伯纳斯-李最初设想的系统里的文档都是只读的，所以只允许用"GET" 动作从服务器上获取HTML文档，并且在响应请求之后立即关闭连接，功能非常有限。

HTTP 1.0

1996年正式发布

1. 增加了HEAD、POST等方法
2. 增加了响应状态码，标记可能的错误原因
3. 引入了协议版本号概念，
4. 引入了HTTP header头概念
5. 传输的数据不仅限于文本

在1.0中服务器发送完一个http响应后，会断开连接。1.0中确立了大部分现在使用的技术，但是它还不是一个正式的标准

HTTP 1.1

1999年，HTTP1.1发布了RFC文档，http1.1是目前互联网上使用最广泛的协议，功能也十分完善。

1. 增加了PUT、 DELETE等新的方法;
2. 增加了缓存管理和控制;
3. 明确了连接管理，允许持久连接;
4. 允许响应数据分块(chunked)，利于传输大文件;
5. 强制要求Host头，让互联网主机托管成为可能。

1.1中把connection 头写进标准，默认开启久连接，connection：keep-alive。什么时候关闭？timeout=20；设置超时时间；max = xxx；长连接最多接收xxx次请求就断开。

HTTP 2.0

相对于HTTP 1.1来说

1. 提升访问速度
2. 允许多路复用
3. 二进制分帧, HTTP 1.x的解析是基于文本，基于文本协议的格式解析存在天然缺陷。
4. 首部压缩，HTTP 1.x中header有大量信息，且每次都重复发送，HTTP 2.0用encoder减少传输header大小，通讯双方各cashe一份header fileds表。
5. 服务器推送（server push）

http2.0 基于Google的SPDY协议，注重性能改善，但还没有普及。

http3.0

http3.0基于Google的QUIC协议，是将来的发展方向。

Q1: 一个tcp连接可以对应几个http请求？

在长连接里可以对应多个

Q2: tcp连接中http请求发送可以一起吗？

在1.1中，pipelining技术可以完成多个请求同发，但是浏览器默认关闭，所以仍然认为不可行，在2.0中，Multiplexing多个请求可以在同一个tcp连接中并行进行。

Q3： 浏览器如何提高页面加载的效率？

同一个连接顺序处理多个或者和服务器建立多个tcp连接。

https请求过程

详解

HTTPS是一种应用层协议，本质上来说它是HTTP协议的一种变种。HTTPS比HTTP协议安全，因为HTTP是明文传输，而HTTPS是加密传输，加密过程中使用了三种加密手段，分别是证书，对称加密和非对称加密。HTTPS相比于HTTP多了一层SSL/TSL。

非对称加密

非对称加密算法对加密的数据有长度限制（128字节），速度慢，安全级别高。对称加密公钥私钥相同，对加密的数据没有长度限制，速度快，安全级别低。

非对称加密流程：A端向B端请求，B端返回公钥给A端，然后A端使用公钥加密，传递给数据报文给B端，B端使用自己的私钥进行解密。

HTTPS请求过程

HTTPS作为一种安全的应用层协议，它使用了以上三种加密手段，我们现在尝试分析其加密的思想。

首先，数据正文一般数据量较大，适用于对称加密，因为对称加密速度快，适应于大量数据加密，但是安全级别低，其中对称加密的密钥需要在网络中传输，容易被盗取；

其次，正因为对称加密的密钥易被盗取，所以我们需要对这个密钥进行加密，而且安全级别要求高，所以这个可以用非对称加密算法进行加密，原因是对称加密的密钥数据量小，非对称加密可以提供高安全级别和高响应速度。

最后，由于非对称加密的公钥可以在网络中传输，如何保证公钥传送到给正确的一方，这个时候使用了证书来验证。证书不是保证公钥的安全性，而是验证正确的交互方。可以使用下图进行说明：

上述过程就是两次HTTP请求，详细过程如下:

1. 客户端向服务器发起HTTPS的请求，连接到服务器的443端口；
2. 服务器将非对称加密的公钥连同本身的数字签名证书回传给客户端;
3. 客户端验证服务器返回的证书，如果有问题，则HTTPS请求无法继续；如果没有问题，则上述公钥是合格的，客户端这个时候随机生成一个密钥，称为client key(客户端密钥)，即用于对称加密数据的密钥，然后使用前面的公钥对client key进行非对称加密成密文，至此，HTTPS中的第一次HTTP请求结束。
4. 客户端发起第二次HTTP请求，将加密之后的client key发送给服务器；
5. 服务器使用私钥进行解密，得到解密后的client key，然后使用client key对数据进行对称加密；
6. 将对称加密后的数据发送给客户端，客户端收到后对密文进行对称解密，得到服务器发送的数据，这样HTTPS中的第二次HTTP请求结束。HTTPS请求完成。

11.https请求与http的区别

• HTTPS是密文传输，HTTP是明文传输；
• 默认连接的端口号是不同的，HTTPS是443端口，而HTTP是80端口；
• HTTPS请求的过程需要对CA证书进行验证身份以保证客户端请求到正确的服务器端，传回的响应是来自于正确的服务器端，而HTTP则不需要CA证书；
• HTTPS=HTTP+加密+认证+完整性保护。

12.HTTP状态码

200：请求成功
301：永久重定向
302：临时重定向
400：请求报文中存在语法错误
403：服务器拒绝该次访问（访问权限出现问题）
404： 无法请求该资源
502： 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

13.常用端口

HTTP: 80
HTTPS :443
FTP : FTP服务器有2个端口，一个数据端口20和一个命令（控制）端口21。
SSH : 22
Telnet : 23
SMTP : 25
tomcat: 8080
redis: 6379

14.FTP

1. 打开熟知的端口（21），使客服进程能够连接上。
2. 等待客户进程发出连接请求。
3. 启动从属进程来处理客户进程发来的请求，从属进程对客户进程的请求完毕后即终止，但从属进程在运行期间根据需要可以创建其他子进程。
4. 主进程回到等待状态，继续接受其它客户进程发来的请求，另外有若干个从属进程负责处理单个请求。