计算机网络
1. 网络分层模型
-
OSI七层模型
应用层
网络服务与最终用户的一个接口。
协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP表示层
数据的表示、安全、压缩。（在五层模型里面已经合并到了应用层）
格式有，JPEG、ASCll、EBCDIC、加密格式等会话层
建立、管理、终止会话。（在五层模型里面已经合并到了应用层）
对应主机进程，指本地主机与远程主机正在进行的会话传输层
定义传输数据的协议端口号，以及流控和差错校验。
协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层网络层
进行逻辑地址寻址，实现不同网络之间的路径选择。
协议有：ICMP IGMP IP（IPV4 IPV6）数据链路层
建立逻辑连接、进行硬件地址寻址、差错校验 [3] 等功能。（由底层网络定义协议）
将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。物理层
建立、维护、断开物理连接。（由底层网络定义协议） -
TCP/IP 四层模型
应用层
运输层
网络层
数据链路层
2. 三握四挥
-
为什么要握手
为了保证可靠性传输，TCP需要两边维护socket，序列号，和窗口大小（流量控制用），握手就是为了在数据开始传输前让客户端和服务器准确无误的交换上述信息。需要握手的原因：
- 阻止已经失效的历史请求的初始化【谢希仁】
- 只有通过三次握手才能交换序列号
-
为什么要三次握手
因为第一二次握手只是让客户端知道了客户端发送的请求服务器端可以收到，服务器端发送的请求客户端自己也能收到，但是对服务器端来说，它只知道客户端发送的请求自己能收到，但是自己发送的请求不知道客户端能不能收到，所以需要第三次握手来让服务器端知道，这也是建立连接需要的最少次数。
-
为什么是三握四挥而不是四握四挥
因为TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即与挥手相比，第二次握手的时候服务器端将确认接收报文和请求连接报文合在一起发给了客户端，所以相比四挥少了一次。
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
-
为什么客户端在TIME-WAIT阶段要等2MSL
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。
MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”
3. ICMP协议的应用
ping命令和traceRoute:
tracert（traceroute）工具
tracert和traceroute是一样的意思，只是一个常用在华为设备上，一个用在思科设备上
可以跟踪网络中从源节点到目标节点中间所经过的所有三层节点信息
tracert（traceroute）和ping一样可以跟IP和域名
这两个工具常用于检查连通性和排查故障节点
4. TCP如何保证可靠性
TCP协议详解
+
校验和:
计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
5. 如何实现UDP的可靠传输
UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响。
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。
最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。
-
添加seq/ack机制，确保数据发送到对端
-
添加发送和接收缓冲区，主要是用户超时重传。
-
添加超时重传机制。
详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。
目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。
6. HTTPS的请求过程（SSL握手过程）
| 步骤 | 内容 | 说明 |
|---|---|---|
| 客户端 -> 服务器 | Client Hello | 传输客户端支持的加密组合、SSL版本与随机数Random1（质数） |
| 服务器 -> 客户端 | Server Hello | 选择客户端支持的加密方法与随机数Random2等 |
| Certificate | 服务端将自己的证书下发给客户端，让客户验证自己的身份，客户端验证通过后取出证书中的公钥 | |
| Server Key Exchange | RSA：不需要 DHE / ECDHE：需要 | |
| Server Hello done | 通知客户端 Server Hello 结束 | |
| 客户端 -> 服务器 | Client Key Exchange | 客户端验证通过的证书取出公钥，生成并利用公钥加密随机数：preMaster secret，将其发给服务端。服务端利用私钥解密获得随机数。 至此，客户端与服务端都拥有三个随机数，双方根据约定的算法生成一个秘钥master secret。之后的数据传输都是用这个密钥进行加解密 |
| Change Cipher Spec | 客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥master secret加密 | |
| Encrypted Handshake Message | 代表了握手结束。客户端将握手消息等数据生成摘要再用master secret加密。 服务端接收后解密，并验证数据。 | |
| 服务器 -> 客户端 | Change Cipher Spec | 同上 |
| Encrypted Handshake Message |
整个过程分为以下几步：
-
客户端浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。
-
服务器收到请求，选择浏览器支持的加密算法和哈希算法。
-
服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的。
（注释：证书包括以下这些内容：1. 证书序列号。2. 证书过期时间。3. 站点组织名。4. 站点DNS主机名。5. 站点公钥。6. 证书颁发者名。7. 证书签名。因为证书就是要给大家用的，所以不需要加密传输） -
浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的：
(1) 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。
(2) 用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性（验证过程类似上面 Bob 和 Susan 的通信）。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。
(3) 浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密
-
浏览器将加密的 R 传送给服务器。
-
服务器用自己的私钥解密得到 R。
-
服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器，
浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。
7. 输入网址到浏览器显示页面经历的过程
- 浏览器缓存 -> 系统缓存(c盘/host) -> 本地域名服务器(LDNS) -> Root Server域名服务器
- DNS域名解析系统本质就是一个数据服务器，里面存储了域名和IP的对应关系
- 最后会得到一个IP地址，通过这个IP地址，才能访问一台服务器
- 得到一个地址后，就能知道我们要访问哪一台服务器了
- 客户端和服务端进行tcp的三次握手建立连接
- 客户端发送HTTP请求，服务端响应请求
- 客户端根据用户操作，如按下回车键，向服务器发送HTTP请求
- 服务器接受请求，然后进行处理，整合需要的资源，通过HTTP协议传输响应发送给客户端浏览器
- 浏览器解析渲染页面
- 连接结束
8. DNS协议用到了什么传输层协议？
为什么既使用TCP又使用UDP？
首先了解一下TCP与UDP传送字节的长度限制：
UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。
DNS占用53号端口，同时使用TCP和UDP协议。那么DNS在什么情况下使用这两种协议？
DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议。
区域传输的时候使用TCP协议：
-
辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
-
TCP是一种可靠连接，保证了数据的准确性。
域名解析时使用UDP协议：
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
9. HTTP、TCP、IP报文的结构
HTTP请求报文结构：
HTTP响应报文结构：
状态码说明：
-
1XX 请求正在处理
-
2XX 请求成功
200 OK 正常处理 204 no content 请求处理成功但没有资源可返回 206 Partial Content 对资源的某一部分请求 -
3XX 重定向
301 Moved Permanenly请求资源的URI已经更新（永久移动），客户端会同步更新URI。 302 Found 资源的URI已临时定位到其他位置，客户端不会更新URI。 303 See Other 资源的URI已更新，明确表示客户端要使用GET方法获取资源。 304 Not Modified 当客户端附带条件请求访问资源时资源已找到但未符合条件请求。 307 Temporary Redirect临时重定向 -
4XX 客户端错误
400 Bad Request 请求报文中存在语法错误，一般为参数异常。 401 Unauthorized 发送的请求需要HTTP认证。 403 Forbiddden 不允许访问，对请求资源的访问被服务器拒绝 404 Not Found 无法找到请求的资源，请求资源不存在。 405 请求的方式不支持。 -
5XX 服务器错误
500 Internal Server Error 服务器的内部资源出故障，服务器在执行请求时发生了错误。 503 Service Unavailable 服务器暂时处于超负载状态或正在进行停机维护，无法处理请求，服务器正忙。
TCP的报文结构：
IP的报文结构：
10. Get、Post的区别
-
GET参数通过URL传递，POST放在Request body中
-
GET在浏览器回退时是无害的（幂等），而POST会再次提交请求（非幂等）
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同 -
GET产生的URL地址可以被Bookmark，而POST不可以
-
GET请求会被浏览器主动cache，而POST不会，除非手动设置
-
GET请求只能进行url编码，而POST支持多种编码方式
-
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
-
GET请求在URL中传送的参数是有长度限制的，而POST么有
-
对参数的数据类型，GET只接受ASCII字符，而POST没有限制
-
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
