计算机网络

TCP/IP协议体系的认知

答:

(1）分层。一部分处于用户态，一部分处于内核态。数据链路层，网络层，传输层封装于操作系统内核态。应用层存在于操作系统的用户空间，包括DNS，FTP，HTTPs，HTTP，工作中接触较多的是应用层的部分。但其它层的原理必须理解，面试考察。
(2）层与层之间下层对上层是透明的，传输在每一层是对等的。

链路层

以太网帧的格式

MTU（最大传输单元）的概念

ARP协议和RARP协议

（地址协议和逆地址协议，网卡MAC地址和IP地址互查机制),

ARP缓存的原理

ARP报文格式

ARP查询原理

网络层

掌握IP的首部格式

如16位分片标识、DF不分片标志、MF更多分片标志、13位片偏移、8位生存时间TTL、16位的首部检验和等等

掌握IP的分片

总长大于MTU值，画分片情况；如何避免IP分片（在应用层或传输层做限制）；确定分片顺序；确定分片是否全部到达

掌握IP选路

会看路由表。Route print 。路由表每个字段的含义

ICMP协议（因特网控制报文协议）

掌握报文格式
分类：查询 + 差错
两种查询报文+ 五种差错报文

传输层

次要UDP

次要一点，掌握(无连接，不可靠)的特点和首部各个字段

掌握TCP

(面向连接，可靠)特点 + 首部字段 (序号，确认号，首部长度，窗口大小，校验和等特别的，完成可靠功能的部分)
连接控制机制：三次握手，四次挥手，同时打开，同时关闭，半关闭（可能问到为什么需要）
流量控制机制：滑动窗口,慢启动，拥塞避免，快速重传，快速恢复
超时重传机制: 四个定时器
一些问题: 为什么三次握手四次挥手？为什么TCP和UDP都存在尾包头？

应用层

掌握DNS(域名解析)协议

名字空间
指针查询（反向查找或逆向解析）基本原理
DNS缓存

FTP协议（活化石）

控制连接和数据连接: 为什么需要这两种连接
两种工作模式： PASV 和 PORT
各种指令和响应码
FTP断点续传和匿名FTP的概念

HTTP协议

报文格式

请求报文

请求报文通常由三部分组成：

请求行：描述请求或者响应的基本信息

请求行（Request Line）分为三个部分：请求方法、请求地址和协议及版本，以CRLF(rn)结束。HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的两种GET和POST，如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。

请求头：key-value形式说明报文

消息正文：实际传输诸如图片等信息。具体如下图试试

1 请求方法：一共有八种方法选择，如下图所示。采用不同的方法获取不同的资源

说一下非常常见的几种请求方法

注意，仅有POST、PUT以及PATCH这三个动词时会包含请求体，而GET、HEAD、DELETE、CONNECT、TRACE、OPTIONS这几个动词时不包含请求体

Get：从服务器中取资源。可以请求图片，视频等

HEAD:和Get类似，但是从服务器请求的资源不会返回请求的实体数据，只会返回响应头

POST/PUT：对应于GET，向服务器发送数据

请求头各种字段

Header	解释	示例
Accept	指定客户端能够接收的内容类型	Accept: text/plain, text/html,application/json
Accept-Charset	浏览器可以接受的字符编码集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定浏览器可以支持的web服务器返回内容压缩编码类型。	Accept-Encoding: compress, gzip
Accept-Language	浏览器可接受的语言	Accept-Language: en,zh
Accept-Ranges	可以请求网页实体的一个或者多个子范围字段	Accept-Ranges: bytes
Authorization	HTTP授权的授权证书	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定请求和响应遵循的缓存机制	Cache-Control: no-cache
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）	Connection: close
Cookie	HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。	Cookie: $Version=1; Skin=new;
Content-Length	请求的内容长度	Content-Length: 348
Content-Type	请求的与实体对应的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	请求发送的日期和时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	请求的特定的服务器行为	Expect: 100-continue
From	发出请求的用户的Email	From: user@email.com
Host	指定请求的服务器的域名和端口号	Host: www.zcmhi.com
If-Match	只有请求内容与实体相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在实体在指定时间之后未被修改才请求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通过代理和网关传送的时间	Max-Forwards: 10
Pragma	用来包含实现特定的指令	Pragma: no-cache
Proxy-Authorization	连接到代理的授权证书	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只请求实体的一部分，指定范围	Range: bytes=500-999
Referer	先前网页的地址，当前请求网页紧随其后,即来路	Referer: http://www.zcmhi.com/archives...
TE	客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息	TE: trailers,deflate;q=0.5
Upgrade	向服务器指定某种传输协议以便服务器进行转换（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的内容包含发出请求的用户信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中间网关或代理服务器地址，通信协议	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	关于消息实体的警告信息	Warn: 199 Miscellaneous warning

头字段注意事项

<1> 字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；

<2> 字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线”_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；

<3> 字段名后面必须紧接着“:”，不能有空格，而”:”后的字段值前可以有多个空格；

<4> 字段的顺序是没有意义的，可以任意排列不影响语义；

<5> 字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

响应报文

HTTP 响应报文由状态行、响应头部、空行和响应体 4 个部分组成

状态行—-由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成

<1> 版本号：使用的HTTP什么版本

<2> 状态码：不同数字代表不同的结果，就如我们在编码时，通过返回不同的值代表不同的语义。

响应头各种

状态码一共分为5类,请参照下面HTTP状态码。

HTTP状态码

1××：处于中间状态，还需后续操作

2××：成功收到报文并正确处理

"200 OK"
最常见的成功状态码，表示一切正常，客户端获得期许的处理结果。如果不是Head请求，那么在响应头中通常会有body数据。

"204 No Content"
这个的含义和"200"很相似，不同之处在于它的响应头中没有body数据。

"206 Partial Content"
是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。状态码 206 通常还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/5000”，意思是此次获取的是总计 5000 个字节的前 100 个字节。

3××：重定向到其他资源位置

"301 Moved Permanently"
“永久重定向”，意思是本地请求的资源以及不存在，使用新的URI再次访问。

“302 Found”
“Moved Temporarily”，“临时重定向”，临时则所请求的资源暂时还在，但是目前需要用另一个URI访问。

301 和 302 通过在字段Location中表明需要跳转的URI。两者最大的不同在于一个是临时改变，一个是永久改变。举个例子，有时候需要将网站全部升级为HTTPS，这种永久性改变就需要配置永久的"301"。有时候晚上更新系统，系统暂时不可用，可以配置"302"临时访问，此时不会做缓存优化，第二天还会访问原来的地址。

“304 Not Modified”
运用于缓存控制。它用于 If-Modified-Since 等条件请求，表示资源未修改，可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。

4××：请求报文有误，服务器无法处理

"400 Bad Request”
通用错误码，表示请求报文有错误，但是这个错误过于笼统。不知道是客户端还是哪里的错误，所以在实际应用中，通常会返回含有明确含义的状态码。

“403 Forbidden”
注意了，这一个是表示服务器禁止访问资源。原因比如涉及到敏感词汇、法律禁止等。当然，如果能让客户端有一个清晰的认识，可以考虑说明拒绝的原因并返回即可。

“404 Not Found”
这可能是我们都知道且都不想看到的状态码之一，它的本意是想要的资源在本地未找到从而无法提供给服务端，但是现在，只要服务器"耍脾气"就会给你返回 404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，

"405 Method Not Allowed"
获取资源的方法好几种，我们可以对某些方法进行限制。例如不允许 POST 只能 GET；

"406 Not Acceptable"
客户端资源无法满足客户端请求的条件，例如请求需要中文但只有英文；

"408 Request Timeout"
请求超时，服务器等待了过长的时间；

"409 Conflict"：
多个请求发生了冲突，可以理解为多线程并发时的竞态；

413 Request Entity Too Large：
请求报文里的 body 太大；

414 Request-URI Too Long：请求行里的 URI 太大；

429 Too Many Requests：客户端发送了太多的请求，
通常是由于服务器的限连策略；

431 Request Header Fields Too Large：请求头某个字
段或总体太大；

5××：服务器错误，服务器对请求出的时候发生内部错误。

“500 Internal Server Error”
和400 类似，属于一个通用的错误码，但是服务器到底是什么错误我们不得而知。其实这是好事，尽量少的将服务器资源暴露外网，尽量保证服务器的安全。

“502 Bad Gateway”
通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。

“503 Service Unavailable”
表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。

503 是一个“临时”的状态，
暂时比较忙，稍后提供服务。在响应报文中的“Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。

HTTPS协议

从上图我们知道HTTPS无非是在传输层和应用层中间加了一层TLS，正是TLS紧跟当代密码学的步伐，尽全力的保障用户的安全。

HTTPS握手

SSL握手协议对于三次握手

注意：

首先通过非对称加密建立通信过程
在握手阶段，为什么使用3个随机数，一方面防止「随机数 C」被猜出，另一方增加Session key随机性
Client发出支持的「对称/非对称加密」算法
server返回选用的「对称/非对称加密」算法
Client对算法进行确认
Server对算法进行确认

HTTPS摘要算法

摘要算法可以理解为一种特殊的”单向”加密算法，无密钥，不可逆。在平时项目中，应该大家都是用过MD5，SHA-1。但是在TLS中使用SHA-2。

假设小A转账5000给小C，小A加上SHA-2摘要。网站计算摘要并对比，如果一致则完整可信。

此时小B想修改小A给的money，这个时候网站计算摘要就会发现不一样，不可信

数字签名
数字证书

Beyoned's Blog

四层协议