http服务的实现

r囧r小猫 2022-05-15 08:25 209阅读 0赞

<1>linux 环境下了解一下

1.  直接用现成的，Apache / Nginx，python -m SimpleHTTPServer
2.  用库写基本的，Python 的 HTTPServer / CGIHTTPServer 等
3.  用 C 从底层手写：POSIX API, Sockets，**RFC 2616** 。基本的单线程迭代阻塞处理；然后是高级点的优化
    
    1.  I/O multiplexing (select / poll, epoll)
    2.  进程、线程分派模型：one-request-per-child / one-request-per-thread
    3.  非阻塞 I/O，edge trigger
4.  高级功能
    
    1.  性能优化：
        
        1.  Memory caching
        2.  I/O 优化 如 文件系统选择、Linux AIO 等。单这块往下看文件系统、I/O 调度和其它 OS 内核细节，就可以挖非常深
        3.  TCP/IP 优化
    2.  CGI / FastCGI / WSGI / AJK 等后端协议支持
    3.  HTTPS 协议支持
    4.  模块化，扩展模块支持，这块更偏向于架构设计。Apache 就有非常出名的动态模块设计
    5.  集群支持

3 只要看看 APUE / UNP 即可，  
4 需要广泛研究不同的代码和各种技术的文档。

<2>怎么实现

既然想实现一个http服务器，首先必须要熟悉的就是http协议知识，然后在选择具体的模块来完成实现。下面先了解一些http协议知识，然后我们再一步一步来实现它。

## http协议知识 ##

**一、 网络通信简介**

传输层及其以下的机制由内核提供，应用层由用户进程提供，应用程序对通讯数据的含义进行解释，而传输层及其以下处理通讯的细节，将数据从一台计算机通过一定的路径发送到另一台计算机。应用层数据通过协议栈发到网络上时，每层协议都要加上一个数据首部（header），称为封装（Encapsulation）。

假设现在应用层协议为http，那么其中的Data 可以看作是一个http请求或者应答，Data包含真正的消息正文和app首部（即报头等）。

**二、HTTP协议详解之请求篇**

http请求由三部分组成，分别是：请求行、消息报头、请求正文

1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF 其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

> 请求方法（所有方法全为大写）有多种，各个方法的解释如下： GET 请求获取Request-URI所标识的资源 POST 在Request-URI所标识的资源后附加新的数据 HEAD 请求获取由Request-URI所标识的资源的响应消息报头 PUT 请求服务器存储一个资源，并用Request-URI作为其标识 DELETE 请求服务器删除Request-URI所标识的资源 TRACE 请求服务器回送收到的请求信息，主要用于 [测试][Link 1]或诊断 CONNECT 保留将来使用 OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

2、请求报头后述 3、请求正文(略)

**三、HTTP协议详解之响应篇**

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文 1、状态行格式如下： HTTP-Version Status-Code Reason-Phrase CRLF 其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

> 状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值： 1xx：指示信息--表示请求已接收，继续处理 2xx：成功--表示请求已被成功接收、理解、接受 3xx：重定向--要完成请求必须进行更进一步的操作 4xx：客户端错误--请求有语法错误或请求无法实现 5xx：服务器端错误--服务器未能实现合法的请求

2、响应报头后述

3、响应正文就是服务器返回的资源的内容

**四、HTTP协议详解之消息报头篇**

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。 每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1、普通报头 在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。 Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。 请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached; 响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

Date普通报头域表示消息产生的日期和时间

Connection普通报头域允许发送指定连接的选项。

2、请求报头 请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。 常用的请求报头 Accept Accept-Charset Accept-Encoding Accept-Language Authorization Host（发送请求时，该报头域是必需的） User-Agent

3、响应报头 响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。 常用的响应报头 Location Server WWW-Authenticate

4、实体报头 请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。 常用的实体报头 Content-Encoding Content-Language Content-Length Content-Type Last-Modified Expires GMT

**五、HTTP协议相关技术补充**

1、基础： 高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等 中介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)，一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过 URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一 个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道经常被使用。 代理(Proxy)：一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的 服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处 理没有被用户代理完成的请求。 网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。 网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。 通道(Tunnel)：是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继 的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。

2、协议分析的优势—HTTP分析器检测网络攻击 以模块化的方式对高层协议进行分析处理，将是未来入侵检测的方向。 HTTP及其代理的常用端口80、3128和8080在network部分用port标签进行了规定

3、HTTP协议Content Lenth限制漏洞导致拒绝服务攻击 使用POST方法时，可以设置ContentLenth来定义需要传送的数据长度，例如ContentLenth:999999999，在传送完成前，内 存不会释放，攻击者可以利用这个缺陷，连续向WEB服务器发送垃圾数据直至WEB服务器内存耗尽。这种攻击方法基本不会留下痕迹。

4、利用HTTP协议的特性进行拒绝服务攻击的一些构思 服务器端忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYNFlood攻击（SYN洪水攻击）。 而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。本文用“正常连接”的方法来产生拒绝服务攻击。 19端口在早期已经有人用来做Chargen攻击了，即Chargen\_Denial\_of\_Service，但是！他们用的方法是在两台Chargen 服务器之间产生UDP连接，让服务器处理过多信息而DOWN掉，那么，干掉一台WEB服务器的条件就必须有2个：1.有Chargen服务2.有HTTP 服务 方法：攻击者伪造源IP给N台Chargen发送连接请求（Connect），Chargen接收到连接后就会返回每秒72字节的字符流（实际上根据网络实际情况，这个速度更快）给服务器。

<3>简单的思路

最简单的http服务器能实现如下功能即可：  
1，使用socket，监听某端口（比如80）  
2，收到请求header，解析header中的地址  
3，按地址取资源（可以理解为就是文件），生成响应header，把文件内容加在生成的响应header中返回

<4>简单的步骤

服务器基本功能要求：

1.  服务器框架
    
    1.  能够处理并发连接请求
    2.  能够处理超时的连接（长时间无动作的连接要删除掉）
    3.  消息的接收
    4.  消息的发送
    5.  发送失败或者接收失败的异常处理
2.  HTTP协议处理模块
    
    1.  HTTP协议解析
    2.  HTTP协议构造
3.  可以对日志信息的输出
    
    1.  多线程
    2.  消息队列
    3.  日志的不同级别输出
4.  业务逻辑

涉及知识点：  
1.并发服务器框架

*   *  TCP协议
     *  EPOLL 的使用（主要用来实现并发）
     *  多线程编程
     *  并发服务器处理模型

2.HTTP协议

*   *  对HTTP协议要懂

3.日志系统

*   *  锁
     *  信号量
     *  消息队列

4.业务逻辑

*   *  消息到手自己想怎么处理就怎么处理了

[Link 1]: https://link.zhihu.com/?target=http%3A//lib.csdn.net/base/softwaretest