【网络基础知识】网络基础知识点归纳梳理

1. 常用的网络传输协议

• TCP：传输控制协议，可靠传输，面向连接
• UDP：用户数据包协议，不可靠传输，面向无连接
• FTP：文件传输协议,用于上传和下载文件
• HTTP：超文本传输协议，基于TCP/IP通信协议，面向对象
• SMTP：邮件传输协议
• TELNET：Internet远程登录服务的标准协议和主要方式
• DNS：域名系统，将域名解析为ip地址

2. ICMP协议与IGMP协议

ICMP（Internet Control Message Protocol）Internet控制报文协议，是一种面向无连接的网络层协议，是TCP/IP协议族的一个子协议，用于主机、路由器之间传递控制消息。ICMP协议的主要功能是确认IP包是否成功到达目标地址，通知在发送过程中IP包被丢弃的原因。

IGMP（Internet Group Management Protocol）Internet组管理协议，是TCP/IP协议族中负责IPV4组播成员管理的协议。IGMP协议用来接收主机与其直接相邻的组播路由器之间建立和维护组播成员关系，通过在接受主机和组播路由器之间交互IGMP报文实现组成员管理功能，IGMP报文封装在IP报文中，IGMP共有v1、v2、v3三个版本。

3. ARP协议与RARP协议

ARP（Address Resolution Protocal）地址解析协议，其基本功能为透过目标设备的IP地址，查询目标的MAC地址，以保证通信顺利进行。它是IPv4网络层必不可少的协议，不过在IPv6已经不再适用，并被邻居发现协议（NDP）所替代。

RARP（Reverse Address Resolution Protocol）反向地址转换协议允许局域网的物理机器从网关服务器的ARP表或缓存上请求IP地址。网络管理员在局域网网关路由器里创建一个表以映射物理地址（MAC）和与其对应的IP地址，当设置一台新的机器时，其RARP客户机程序需要想路由器上的RARP服务器请求响应的IP地址。

4. TCP与UDP的区别

• TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）；UDP提供无连接的传输，通信前不需要建立连接。
• TCP提供可靠的传输（有序、无差错、不丢失、不重复）；UDP提供不可靠的传输。
• TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组；UDP是面向数据报文的传输，没有分组开销。
• TCP首部开销20字节；UDP的首部开销小，只有8字节。
• TCP的逻辑通信信道是全双工的可靠信道；UDP是不可靠信道。
• TCP提供拥塞控制和流量控制机制；UDP不提供拥塞控制和流量控制。

应用场景：

• 对数据可靠性的要求高的应用需要选择TCP协议，如验证密码；而对数据可靠性要求不那么高的可以选择UDP协议。
• 对应用实时性要求高的因公可以选择UDP协议，如视频监控等。
• 在网络状况不好的情况下需选用TCP协议，如广域网；而网络状况很好的情况下就不需要采用TCP协议，建议选择UDP协议来减少网络负荷，如局域网。

5. 常见的状态码

状态码	状态	描述
200	Ok	请求成功
204	No Content	请求被受理但没有资源可以返回
206	Partial Content	客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法
301	Moved Permanently	永久性重定向
302	Found	临时重定向
303	See Other	与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304	Not Modified	发送附带条件的请求时，条件不满足时返回，与重定向无关
307	Temporary Redirect	临时重定向，与302类似，只是强制要求使用POST方法
400	Bad Request	请求语法错误，不能被服务器解析
401	Unauthorized	未经授权，需与www-Authenticate一起用
403	Forbidden	服务器收到请求，但拒绝提供服务
404	Not Found	请求资源不存在
500	Internal Server Error	服务器发生不可预期的错误
503	Server Unavailable	服务器当前不能处理客户端的请求，一段时间后可能恢复正常

总之，HTTP状态码分为5个类别：

• 1xx：指示信息–表示请求已接收，继续处理
• 2xx：成功–表示请求已被成功接收、理解、接受
• 3xx：重定向–要完成请求必须进行更进一步的操作
• 4xx：客户端错误–请求有语法错误或请求无法实现
• 5xx：服务器端错误–服务器未能实现合法的请求

参考来源

6. 三次握手

• 第一次握手：建立连接时，客户端发送SYN包（SYN=1,seq=x）到服务器，并进入同步已发送状态（SYN_SENT），等待服务器确认。状态过程：SYN=1, seq=x。
• 第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1）,同时自己也发送一个SYN包（seq=y），即SYN+ACK包（SYN=1,ACK=1），服务器进入同步收到状态（SYN_RECV）。状态过程：SYN=1, ACK=1, seq=y, ack=x+1。
• 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认ACK包（ack=y+1），此包发送完毕，客户端和服务器进入已建立连接状态（ESTAB_LISHED），完成握手。状态过程：ACK=1, seq=x+1, ack=y+1。

7. 四次挥手

• 第一次挥手：客户端进程发出连接释放报文，并停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（实际上等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入终止等待1状态（FIN_WAIT_1）。TCP规定，FIN报文段即使不携带数据也要消耗洗个序号。状态过程：FIN=1, seq=u。
• 第二次挥手：服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时服务端就进入等待关闭状态（CLOSE-WAIT）。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但服务器若发送数据，客户端依然要接受。客户端收到服务器的确认请求后，此时客户端就进入了终止等待状态2（FIN-WAIT-2），接受服务器发送的最后的数据并等待服务器发送连接释放报文。状态过程：ACK=1, seq=v, ack=u+1。
• 第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能有发送了一些数据，假定此时的序列号为seq=w，此时服务器就就进入了最后确认状态（LAST-ACK），等待客户端确认。状态过程：FIN=1, ACK=1, seq=w, ack=u+1。
• 第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时客户端就进入了时间等待状态（TIME-WAIT）。此时TCP连接还没有释放，必须经过最长报文段寿命（2MSL）的时间后，当客户端撤销相应的TCB后，服务器就接收到客户端发出的确认，才进入CLOSED状态。状态过程：ACK=1, seq=u+1, ack=w+1。

8. 为什么连接的时候是三次握手，关闭的时候却是四次握手

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

9. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态

按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

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

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

11. session和cookie的区别

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，客户端会把Cookie保存起来。

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录，以便再次访问时确认身份。每个用户访问服务器都会建立一个session，用户与服务器建立连接的同时，服务器会自动为其分配一个SessionId。

session和cookie的区别：

• cookie数据存放在客户的浏览器上，session数据放在服务器上
• cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session
• session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie
• 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
• 可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中

应用场景：

• 登录网站，今输入用户名密码登录了，第二天再打开很多情况下就直接打开了。这个时候用到的一个机制就是cookie
• session一个场景是购物车，添加了商品之后客户端处可以知道添加了哪些商品，而服务器端如何判别呢，所以也需要存储一些信息就用到了session

12. 对称加密和非对称加密

• 对称加密

即加密密钥和解密密钥相同，如DES、AES等。

• 非对称加密

将加密密钥分为公钥和私钥，公钥可以公开，私钥是保密的；客户端用公钥加密数据，服务端可以用私钥解密。如RSA、ECC等。

13. HTTP和HTTPS的区别

HTTP协议传输的数据都是为加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能够加密传输，引入了SSL（Secure Sockets Layer）协议对HTTP协议传输的数据进行加密，因此HTTPS等同于HTTP + SSL。

HTTPS协议简单来说就是HTTP + SSL协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议更加安全。

HTTP与HTTPS的主要区别：

• HTTP是超文本传输协议，信息是明文传输，是不安全的，而HTTPS则是具有安全性的SSL加密传输协议，是安全的；
• HTTPS协议需要到CA申请签名颁发的SSL证书，而HTTPS无需证书；
• HTTP和HTTPS使用的是完全不同的链接方式，用的端口也不一样，HTTPS默认采用80作为通信端口，而HTTPS默认采用443为通信端口；
• 在OSI网络模型中，HTTP工作于应用层，而HTTPS的安全协议机制工作于传输层。

14. HTTP协议是无状态协议，怎么解决

无状态协议对于事务处理没有记忆能力，无状态记录导致同一客户端HTTP请求完成后，再次发送HTTP请求时，HTTP不知道当前客户端是一个“老客户”。

解决：使用Cookie，Cookie相当于一个身份通行证，客户端第一次访问时给客户端发一个Cookie，当该客户端再次访问时，验证Cookie服务器就可放行。

参考来源

15. 常用HTTP方法有哪些

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

16. HTTP请求报文和响应报文

请求报文包含四个部分：

• 请求行：请求方法、URI、HTTP版本信息
• 请求首部字段
• 请求内容实体
• 空行

响应报文包含四个部分：

• 状态行：HTTP版本、状态码、状态码的原因短语
• 响应首部字段
• 响应内容实体
• 空行

17. HTTP协议常见的首部

通用首部字段

• Date: 创建报文时间
• Connection: 连接管理
• Cache-Control：缓存控制
• Transfer-Encoding：报文主体的传输编码方式

请求首部字段

• Host: 请求资源所在服务器
• Accept: 可处理的媒体类型
• Accept-Charset: 可接受的字符集
• Accept-Encoding: 可接受的内容编码
• Accept-Language: 可接受的自然语言

响应首部字段

• Accept-Ranges: 可接受的字节范围
• Location：令客户端重定向到的URI
• Server：HTTP服务器的安装信息

实体首部字段

• Allow：资源可支持的HTTP方法
• Content-Type：实体主类的类型
• Content-Encoding：实体主体适用的编码方式
• Content-Language：实体主体的自然语言
• Content-Length：实体主体的字节数
• Content-Range：实体主体的范围，一般用于发出部分请求时使用

18. http的头部，keep-alive的作用

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：Connection: keep-alive，TCP连接在发送后将仍然保持打开状态，这时浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

19. 一次完整的HTTP请求的过程

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间经过以下7个步骤：

• （1）建立TCP连接：TCP/IP协议构建连接网络
• （2）Web浏览器向Web服务器发送请求命令：HTTP/1.1
• （3）Web浏览器发送请求头
• （4）Web服务器应答：HTTP/1.1 200 OK
• （5）Web服务器发送应答头: 发送服务器自身信息及被请求的文档
• （6）Web服务器向浏览器发送数据：以Content-Type应答头信息所描述的格式发送用户所请求的实际数据
• （7）Web服务器关闭TCP连接：弱项保持连接则需要在头信息加入Connection: keep-alive

20. HTTP1.0与HTTP1.1的区别

参考来源

缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since, Expires来做缓存判断的标准，HTTP1.1则引入了更多缓存控制策略，如Entity tag, If-Unmodified-Since, If-Match, If-None-Match等更多可供闲着的缓存头来控制缓存策略。

带宽优化及网络连接的使用：在HTTP1.0中，存在一些浪费带宽的现象，如客户端是需要某个对象的一部分，而服务器却将整个对象发送过来了，并且不支持断点续传功能；在HTTP1.1中，在请求头引入了Range头域，它允许只请求资源的某个个部分，即返回码是206（Partial Content），这使得开发者可以自由选择，以便充分利用带宽和连接。

错误通知管理：在HTTP1.1中新增了24个错误状态响应码，如409表示请求资源与资源当前的状态发生冲突；410便是服务器上的某个资源被永久删除。

Host头处理：在HTTP1.0中认为每台服务器都绑定唯一的IP地址，因此请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且他们共享一个IP地址；在HTTP1.1中，请求消息和响应消息都支持Host头域，且请求消息中如果没有Host头域会报告400（Bad Request）。

长连接：HTTP1.1支持长连接（Persistent Connection）和请求的流水线处理（Pipelining），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection: keep-alive，一定程度受伤弥补了HTTP1.0每次请求都要创建连接的缺点。

新增Request方法：HTTP1.1增加了OPTIONS、PUT、DELETE、TRACE、CONNECT这些Request方法。

21. HTTP2.0与HTTP1.x的区别

参考来源

二进制格式（Binary Format）：HTTP1.x的解析是基于文本协议格式解析的，存在缺陷不够健壮；而HTTP2.0的协议解析采用的是二进制格式，通用更健壮。

多路复用（MultiPlexing）：即连接共享，每个request都是使用连接共享机制，一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机混杂在一起，接收方可以根据request的id将request归属到各自不同的服务端请求里。

header压缩：在HTTP1.x的header中带有大量的信息，而且每次请求都要重复发送，而HTTP2.0中使用encoder来减少需要传输的header的大小，通讯双方各自cache一份header fields表，既避免了重复传输header，又减少了需要传输的大小。

服务端推送（Server Push）：同SPDY一样，HTTP2.0也具有Server Push的功能，如网页有个style.css的请求，在客户端接收到style.css数据的同时，服务端会将style.js的文件推送给客户端，但客户端再次尝试获取style.js时就可以直接从缓存中获取，就不用在发请求了。

22. 一次完整的HTTPS请求的过程

图解HTTPS

• （1）客户端发起HTTPS请求：浏览器输入网址，连接服务器的443端口；
• （2）服务器收到请求：选择浏览器支持的加密算法和哈希算法；
• （3）服务器将数值证书返回给客户端：证书序列号、证书过期时间、站点组织名、站点DNS主机名、站点公钥、证书颁发者、证书签名；
• （4）客户端解析证书：由浏览器内置的TSL完成的，验证公钥是否有效，无误这生成一个随机值R，并用证书对随机值R进行加密；
• （5）客户端传送加密后的随机值R：服务端获得这个加密的随机值，加密解密的钥匙；
• （6）服务端解密信息：服务器用自己的私钥解密得到随机值R（即客户端的私钥）；
• （7）传输加密内容信息：服务端使用R对网页内容进行对称加密，并发送给客户端；
• （8）客户端解密内容信息：客户端用自己生成的私钥对服务端传过来的网页内容进行解密。

23. TCP拥塞控制

TCP拥塞控制

• 慢开始和拥塞避免

发送方维持一个拥塞窗口cwnd的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态地变化；发送方让自己的发送窗口等于拥塞窗口，控制拥塞窗口的原则是只要网络没有出现拥塞，拥塞窗口就在增大一些，以便把更多的分组发送出去；但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络的分组数。

慢开始算法：慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段，目的是试探网络的拥塞情况，然后在cwnd加倍增大。为了防止拥塞窗口cwnd增长过大引起网络拥塞，设置一个慢开始门限ssthresh状态变量，当cwnd < ssthresh时，使用慢开始算法；当cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法；当cwnd = ssthresh 时，既可使用慢开始算法也可以使用拥塞避免算法。

拥塞避免算法：每经过一个往返时间RTT就把发送方的拥塞窗口cwnd+1，按线性规律缓慢增长，而不是加倍增长，所以比慢开始算法的拥塞窗口增长速率缓慢得多。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就要把慢开始门限ssthresh设置为出现拥塞时发送方窗口子的一半（且>=2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法，如此迭代重复，直到迅速减少主机发送到网络中的分组数，使得积压的分组处理完毕。

• 快重传和快恢复

快重传算法：首先要求接收方每收到一个失序的报文段后就立即发出重复确认，而不会等到自己发送数据时才进行捎带确认。发送方一连收到三个重复确认就应当立即重传对方未接收到的报文段，而不用继续等待为发送成功报文段设置的重传计时器到期，提高整个网络吞吐量约20%。

快恢复算法：当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半，与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

25. urllib和urllib2

urllib提供urlencode方法用来GET查询字符串的产生，而urllib2没有。这是为何urllib常和urllib2一起使用的原因。

urllib2可以接受一个Request对象来为URL请求设置headers(请求头)，urllib仅可以接受URL，不能伪装用户代理User Agent字符串等。

27. POST和GET的区别

• GET主要是读取资源，POST主要是改写/新建资源
• 不可以重复的操作， 比如创建一个条目/修改一条记录， 用POST, 因为POST不能被缓存，所以浏览器不会多次提交。
• 可以重复的交互，比如取个数据，跳个页面， 用GET。
• GET请求的URL可以手动输入，请求的URL可以存在书签里，或者历史里，且URL可以被搜索引擎收录。
• GET是幂等的、只读的、纯粹的操作，而POST是非幂等的操作。

28. python中实现IO多路复用

I/O多路复用指：通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用如下场合：

• （1）当客户处理多个描述字时（一般是交互式输入和网络套接口），必须使用I/O复用；
• （2）当一个客户同时处理多个套接口时，而这种情况是可能的，但很少出现；
• （3）如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用；
• （4）如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用；
• （5）如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用；

与多进程多线程相比，I/O多路复用技术的最大优势就是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减少了系统的开销。

30. python常用的并发网络库

（1）tornado：并发网络库，同时也是一个Web微框架

Tornado 适用于微服务，实现 Restful 接口

• 底层基于Linux多路复用
• 可以通过协程或者回调实现异步编程
• 不过生态不完善，相应的一步框架步入ORM不完善

（2）gevent：绿色线程实现并发，猴子补丁修改内置socket

Gevnet高性能的并发网络库

• 基于轻量级绿色线程实现并发
• 需要monkey patch，gevent修改了内置的socket改为非阻塞
• 配合gunicorn和gevent部署作为wsgi server

（3）asyncio：python3 内置的并发网络库，基于原生的协程

Asyncio基于协程实现的内置并发网络库

• python3 引用到内置库，协程+事件循坏
• 生态不够完善，没有大规模的生产环境检验
• 目前应用不够广泛，基于Aiohttp可以实现一些小的服务

31. 什么是前后端分离，优缺点各是什么

后端只负责提供数据接口，不在渲染模版，前端从接口获取数据并呈现

优点：

• 实现前后端解耦，接口复用，减少开发量
• 前后端各司其职，同步开发，提升开发效率
• 有利于调试、测试与运维部署
• 有利于快速定位问题，前端问题前端解决，接口数据问题后端解决
• 大并发的情况下，可以同时水平扩展前后端服务器
• 减少后端服务器的并发/负载压力，前端http请求在nginx上，后台接口请求调用tomcat
• 即使后端服务器暂时超时或者宕机了，前端页面也会正常访问，只不过数据显示不出来而已

缺点：

• 不利于页面SEO优化
• 前端工作量加大

32. nginx与apache的区别

nginx相对apache的优点：

• 轻量级，起同样的web服务，比apache占用更少的内存及资源
• 抗并发，nginx处理请求是异步阻塞的，支持更多的并发连接，而apache则是阻塞型的，在高并发下nginx能保持低资源低消耗但高性能
• 配置简洁
• 高度模块化的设计，编写模块相对简单
• 社区活跃

apache相对nginx的优点：

• rewrite，比nginx的rewrite更强大
• 模块超多，支持很多
• 比nginx的bug少很多
• 很稳定

33. CGI和WSGI

CGI通用网关接口，是连接web服务器和应用程序的接口，用户通过CGI来获取动态数据或文件等。CGI程序是一个独立的程序，它可以用几乎所有语言来写，包括perl/c/lua/python等。

WSGI（Web Server Gateway interface）是Python应用程序或者框架和Web服务器之间的一种接口，实现Web服务器与Web框架的交互，WSGI的其中一个目的就是让用户可以用统一的语言python编写前后端。

34. RPC

RPC（Remote Procedure Call Protocol）远程过程调用协议，它是一种通过网络远程计算机程序上请求服务，而不需要了解底层网络技术。RPC协议假定某协议传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

35. SOAP

SOAP（Simple Object Access Protocol）简单对象访问协议，是交换数据的一种协议规范，使用在计算机网络Web服务（web service）中，交换带结构信息。SOAP为了简化网页服务器（Web Server）从XML数据库中提取数据时，节省去格式化页面时间，以及不同应用程序之间按照HTTP通信协议，遵循XML格式执行资料互换，使其抽象于语言实现、平台和硬件。

36. RESTful架构

RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。

REST（Representational State Transfer）表层状态转化，表现层其实指的是资源（Resources）的表现层，资源就是网络上一个实体或者一个具体信息，如一张图片，用特定的统一资源定位符（URI）指定；表现层（Representation）是指把资源呈现出来的形式，如文本可以用txt格式、html格式、xml格式、json格式、二进制格式等来表现；状态转化（State Transfer）客户端通过四个HTTP动词，对服务器端资源进行操作，实现表现层状态转化，如GET获取资源、POST新建更新资源、PUT用来更新资源、DELETE用来删除资源等。

RESTful架构一些典型的设计误区

• 最常见的一种设计错误就是URI包含动词，资源一种实体，所以应该名词。
• 另一个设计误区，就是URI中加入版本号，版本号可以再HTTP请求头信息的Accept字段中进行区分。

37. 幂等

HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。

GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次请求得到不同的结果，但它本身没有产生任何副作用，因而是满足幂等性的。

DELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如DELETE http://forrum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或者刷新页面而不用担心引起错误。

POST所对应的URI并非创建的资源本身，而是资源的接受者。比如POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇文章，HTTP响应中包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。

PUT方法所对应的URI是要创建或更新的资源本身。比如PUT http://www.forum/articles/4231的语义是创建或者更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的，因此PUT方法具备幂等性。

持续跟新，更多网络基础知识，详见个人博客归纳。

欢迎留言补充，批评指正！