php面试知识大总结

php面试知识大总结 第一篇

HTTP 请求方法用于告诉服务器要做什么。HTTP 规范中定义了一组常用的请求方法。

例如：GET 方法负责从服务器获取文档，POST 方法会向服务器发送需要处理的数据，OPTIONS 方法用于确定服务器的一般功能，或者服务器处理特定资源的能力

下图描述了七种 HTTP 方法，并不是所有服务器都实现了所有七种方法。有些方法的请求报文中有主体，有些则无主体的请求

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bviZjyBZ-一六七六五三六三六八五八五)(./assets/)]

由于 HTTP 设计易于扩展，除这些方法，其他服务器可能还会实现一些自己的请求方法。这些附加的方法是对 HTTP 规范的扩展，被称为扩展方法

HTTP 定义了一组被称为安全方法的方法。GET 方法和 HEAD 方法都被认为是安全的，这就意味着使用 GET 或 HEAD 方法的 HTTP 请求都不会产生什么动作

安全方法并不一定是什么动作都不执行的（实际上，这是由 Web 开发者决定的）。使用安全方法的目的就是当使用可能引发某一动作的不安全方法时，允许 HTTP 应用程序开发者通知用户。在 Colin 的五金商店的例子中，你的 Web 浏览器可能会弹出一条警告消息，说明你正在用不安全的方法发起请求，这样可能会在服务器上引发一些事件（比如用你的信用卡支付费用）

GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/ 要求服务器实现此方法

HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以：

服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循 HTTP/ 规范，就必须实现 HEAD 方法

与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去

PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。

因为 PUT 允许用户对内容进行修改，所以很多 Web 服务器都要求在执行 PUT 之前，用密码登录

POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（比如，送到一个服务器网关程序中，然后由这个程序对其进行处理）

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子

TRACE 请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过 TRACE 方法主要用于诊断；也就是说，用于验证请求是否如愿穿过了请求/响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生效果

尽管 TRACE 可以很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各种不同类型请求（不同的方法——GET、HEAD、POST 等）的处理是相同的。很多 HTTP 应用程序会根据方法的不同做出不同的事情——比如，代理可能会将 POST 请求直接发送给服务器，而将 GET 请求发送给另一个 HTTP 应用程序（比如Web 缓存）。TRACE 并不提供区分这些方法的机制。通常，中间应用程序会自行决定对 TRACE 请求的处理方式

TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本

OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。（有些服务器可能只支持对一些特殊类型的对象使用特定的操作）

这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式

DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I零Dc六六Wl-一六七六五三六三七三二三六)(null)]

HTTP 被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在 HTTP/ 规范中定义的方法。服务器会为它所管理的资源实现一些 HTTP 服务，这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。下图列出了一些常见的扩展方法实例。这些方法就是 WebDAV HTTP 扩展包含的所有方法，这些方法有助于通过 HTTP 将 Web 内容发布到 Web 服务器上去

并不是所有的扩展方法都是在正式规范中定义的，认识到这一点很重要。如果你定义了一个扩展方法，很可能大部分 HTTP 应用程序都无法理解。同样，你的 HTTP应用程序也可能会遇到一些其他应用程序在用的，而它并不理解的扩展方法

在这些情况下，最好对扩展方法宽容一些。如果能够在不破坏端到端行为的情况下将带有未知方法的报文传递给下游服务器，代理应尝试传递这些报文。如果可能破坏端到端行为则应以 五零一 Not Implemented（无法实现）状态码进行响应。最好按惯例“对所发送的内容要求严一点，对所接收的内容宽容一些”来处理扩展方法（以及一般的 HTTP 扩展）

php面试知识大总结 第二篇

互联网的通信安全，建立在SSL/TLS协议之上。

本文简要关于SSL/TLS协议的运行机制。文章的重点是设计思想和运行过程，不涉及具体的实现细节。如果想了解这方面的内容，请参阅RFC文档。

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。

互联网加密通信协议的历史，几乎与互联网一样长。

目前，应用最广泛的是TLS ，接下来是SSL 。但是，主流浏览器都已经实现了TLS 的支持。

TLS 通常被标示为SSL ，TLS 为SSL ，TLS 为SSL 。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

解决方法：每一次对话（session），客户端和服务器端都生成一个_对话密钥_（session key），用它来加密信息。由于_对话密钥_是对称加密，所以运算速度非常快，而服务器公钥只用于加密_对话密钥_本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

客户端向服务器端索要并验证公钥。

双方协商生成_对话密钥_。

双方采用_对话密钥_进行加密通信。

上面过程的前两步，又称为_握手阶段_（handshake）。

_握手阶段_涉及四次通信，我们一个个来看。需要注意的是，_握手阶段_的所有通信都是明文的。

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息。

支持的协议版本，比如TLS 版。

一个客户端生成的随机数，稍后用于生成_对话密钥_。

支持的加密方法，比如RSA公钥加密。

支持的压缩方法。

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。二零零六年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

确认使用的加密通信协议版本，比如TLS 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

一个服务器生成的随机数，稍后用于生成_对话密钥_。

确认使用的加密方法，比如RSA公钥加密。

服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供_客户端证书_。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

一个随机数。该随机数用服务器公钥加密，防止被窃听。

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称_pre-master key_。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把_会话密钥_。

至于为什么一定要用三个随机数，来生成_会话密钥_，dog二五零解释得很好：

_不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。_

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的_会话密钥_。然后，向客户端最后发送下面信息。

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用_会话密钥_加密内容。

php面试知识大总结 第三篇

用户数据报协议 UDP 只在 IP 的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及查错检测的功能

用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有八个字节，由四个字段组成，每个字段都是两个字节

当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的终点——应用进程

如果接受方 UDP 发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用程序)，就丢弃该报文，并由网际控制报文协议 ICMP 发送“端口不可达”差错报文给发送方

UDP 用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在 UDP 用户数据报之前增加 一二 个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是 UDP 用户数据报真正的首部。只是在计算检验和时，临时添加在 UDP 用户数据报前面，得到一个临时的 UDP 用户数据报。检验和就是按照这个临时用户数据报来计算的。伪首部既不向下传也不向上递交，而仅仅是为了计算检验和

php面试知识大总结 第四篇

在 TCP 这种字节流协议上做应用层分包是网络编程的基本需求。分包指的是在发生一个消息(message)或一帧(frame)数据时，通过一定的处理，让接收方能从字节流中识别并截取(还原)出一个个消息。因此，“粘包问题”是个伪命题

对于短连接的 TCP 服务，分包不是一个问题，只要发送方主动关闭连接，就表示一个消息发送完毕，接收方 read() 返回零，从而知道消息的结尾

为了提高 TCP 的传输效率，TCP 有一套自己的发送机制

对于长连接的 TCP 服务，分包有四种方法

假如消息格式非常简单，“消息”本身是一个字符串，每条消息有一个四字节的头部，以网络序存放字符串的长度。消息直接没有间隙，字符串也不要求以 ‘\零’ 结尾

发送两条消息“hello”和“smartboy”，打包后的字节流共有二一字节

假设数据最终都全部到达，数据解析逻辑至少能正确处理以下各种数据到达的次序