Web Server 和 HTTP协议(转)

时间:2021-07-29 22:37:12

转自:http://www.kuqin.com/shuoit/20150809/347488.html

一直在找实习,有点什么东西直接就在evernote里面记了,也没时间来更新到这里。找实习真是个蛋疼的事,一直找的是困难模式的C++的后台开发这种职位,主要是因为其他的更不会了。虽然找的是C++的职位,但是我的简历有俩项目都是php的,因为老赵的项目就是用php做网站。最近越来越感觉这样的简历不靠谱,想换个C++的和网络有关的多线程的项目吧。所以最近准备点几个网络和多线程的技能点。于是我看了tinyhttpdLightCgiServer和吴导的husky。基本上对着吴导的husky抄了个paekdusan,但是也不能纯粹的抄一遍啊,所以还是改了一些小东西,大的框架没变。主要的改变包括以下几方面:

  • 在线程池部分中,使用C++11的thread替代了pthread,从而实现跨平台的目标
  • 在支持并发的队列中,使用C++11的mutex和lock替代了pthread的mutex和lock,从而实现跨平台的目标
  • 在socket部分,使用了预编译宏的方式,从而实现跨平台的目标
  • 接收数据部分更健壮,以面对不能一次性读完一个HTTP头部的情况;发送也一样
  • 实现了一个具有简易的KeepAlive策略的HTTP服务器
  • 实现了一个静态文件的HTTP服务器

tinyhttpd和LightCgiServer

首先,还是先介绍一下tinyhttpd吧。网上的评价还是很高的,能让人仅从500-600行的代码中了解HTTP Server的本质。 贴一张tinyhttpd的流程图吧:

Web Server 和 HTTP协议(转)

关于tinyhttpd更详细的信息,大家还是直接去看代码吧,因为真的很易读、易懂。tinyhttpd的代码给人的感觉就是,怎么易读、易懂怎么来,例如服务器回复一个501 Method Not Implemented的response是这么写的,看到我就惊呆了,只能怪我以前看过的代码太少,我第一反应就是先sprintf到一个长的buff里面,然后一起send,但是它这样的写法确实更加易懂、易读。

void unimplemented(int client) {     char buf[1024];        sprintf(buf, "HTTP/1.0 501 Method Not Implementedrn");     send(client, buf, strlen(buf), 0);     sprintf(buf, SERVER_STRING);     send(client, buf, strlen(buf), 0);     sprintf(buf, "Content-Type: text/htmlrn");     send(client, buf, strlen(buf), 0);     sprintf(buf, "rn");     send(client, buf, strlen(buf), 0);     sprintf(buf, "<HTML><HEAD><TITLE>Method Not Implementedrn");     send(client, buf, strlen(buf), 0);     sprintf(buf, "</TITLE></HEAD>rn");     send(client, buf, strlen(buf), 0);     sprintf(buf, "<BODY><P>HTTP request method not supported.rn");     send(client, buf, strlen(buf), 0);     sprintf(buf, "</BODY></HTML>rn");     send(client, buf, strlen(buf), 0); } 

除此之外,值得一提的是tinyhttpd实现的是一个CGI Server的功能,但是在CGI的功能上实现得比较简陋,LightCgiServer实现得更完整一些,关于CGI Server更详细的情况请看CGI Server

husky和paekdusan

正如本文开头所说,大的程序结构上,paekdusan基本是对着husky抄的,只是做了一些小的改变。程序在大的结构上,可以看作是一个生产者消费者模型

先看一个不伦不类的流程图:

Web Server 和 HTTP协议(转)

从上图可以看出,主线程是生产者,线程池中的线程们是消费者,它们之间通过task队列来通信。主线程作为生产者,accept成功返回之后,将处理该client的task添加到task队列中,然后继续accept等待client的到来;线程池的线程们作为消费者,不断的从task队列中取出task,调用task的run接口。

值得注意的是,task队列是一个BoundedBlockingQueue,也就是说,task队列是一个有容量限制,并且阻塞的队列。当消费者试图从task队列中取task时,如果task队列是空的,则消费者会被阻塞,直到生产者往task队列中放入task,将消费者唤醒。同样的,当生产者试图向task队列中放入task时,如果task队列是满的,则生产者会被阻塞,直到消费者从task队列中取出task,将生产者唤醒。

再看一个不伦不类的时序图:

Web Server 和 HTTP协议(转)

这里要求task实现了run接口,task队列的设计可以认为是command模式的实践。看上去有很多类,但是其实是因为每个类的功能比较单一,程序只是把一些功能单一的类组合在一起了而已,其实类之间的耦合性比较低。

具体实现的代码见这里paekdusan

问题记录

  • HTTP协议的基本格式

    HTTP的request的第一部分是request line,以空格分割得到的三部分依次是method,URI和version

    HTTP的request的第二部分是header,header以rn结尾,header中的每一行也以rn结尾,也就是说,当header是空时,以一个rn结尾;当header不空时,一定是以两个连续的rn结尾的。heder中的每一行格式是 key : value,其中value可以是空,所以简单的说,header是一个map,键和值之间用:分隔,键值对之间用rn分隔,在map的最后还有一个rn。值得注意的是,cookie是在header里面的。

    HTTP的request的第三部分是body,协议规定body后面不能再有其他字符,所以body不能靠去找rn来结束,要靠header里面的content-length来指明,content-length就是body的字节数。

    HTTP的response的第一部分是response line,以空格分割得到的三部分依次是version,status code和Reason Phrase

    HTTP的response的第二部分是header,格式和request类似

    HTTP的response的第三部分是body,格式和request类似

    另外,还有一点,我不知道request里面有没有可能出现,反正在response里面是会出现的,那就是如果header中指明了transfer-coding是chunked,那么body将会是一串chunked的块。在HTTP协议的rfc2616中是这么定义chunk-body的格式的:

    Chunked-Body   = *chunk                  last-chunk                  trailer                  CRLF  chunk          = chunk-size [ chunk-extension ] CRLF                   chunk-data CRLF chunk-size     = 1*HEX last-chunk     = 1*("0") [ chunk-extension ] CRLF  chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val  = token | quoted-string chunk-data     = chunk-size(OCTET) trailer        = *(entity-header CRLF) 

    也就是说chunk由四部分组成,首先是若干个chunk块(每个chunk块由chunk-size,可选的chunk-extension,rn, chunk-data 和 rn组成),接着是last-chunk块(chunk-size是0,没有chunk-data的特殊chunk块),然后是trailer(若干和header一样格式的数据组成),最后是一个rn。其实不看中间“可选的chunk-extension”还是比较简单的。

  • KeepAlive的实现

    在之前husky的代码中,server端发送了response之后,就close socket了,即关闭该socket,如果client需要再次发送http request需要再次建立一个新的tcp连接。而打开一个常见的网页,通常有很多http request从client发送到server,那么就需要很多次tcp的建立和断开,比较低效。之所以用KeepAlive就是为了避免多次请求需要重复的建立TCP连接,也就是说server端发送完response之后,不关闭连接,而是在该连接上继续等待数据。KeepAlive在HTTP1.1是默认开启的,如果要关闭,需要在header中声明connection: close。

    但是朴素的KeepAlive会引起一些问题,例如client一直不断开连接,那么和client的连接一直保持,client多了的时候,新来的client无法获得server的资源,所以需要一些其他的折衷。例如如果接下来的5s内都没有收到数据则断开连接,或者是接下来的5s内服务器接收了100个客户端请求就断开连接。

    由于“5s内服务器接收了100个客户端请求就断开连接”这需要在根据一个线程外部的信息控制线程的运行,使得线程运行过程中对于外部的以来过多,故而paekdusan没有这么实现,而是在同一个连接上接收了50个http request之后断开连接。另外paekdusan还实现了“一个连接的持续时间超过5s就断开连接”,具体来说是这样的,recv超时时间1s,每次recv完数据之后判断距离第一次recv的时间是否超过5s,超过则断开连接。详见如下代码:

    //简单起见 删除了一些处理不完整http请求的代码,并且简化了now 和 startTime的设置 //详见https://github.com/aholic/paekdusan/blob/master/KeepAliveWorker.hpp while ((now - startTime <= 5) && requestCount > 0) {     recvLen = recv(sockfd, recvBuff, RECV_BUFFER_SIZE, 0);     if (recvLen <= 0 && getLastErrorNo() == ERROR_TIMEOUT) {         LogInfo("recv returns %d", recvLen);         continue;     }                if (recvLen <= 0) {         LogError("recv failed: %d", getLastErrorNo());         break;     }      //do with recvBuff, get a http request      requestCount--; } 

    但是由于使用的是阻塞的recv,所以实现的不是非常合理,存在一些问题。 例如此时恰好距离第一次recv只有4.99秒,所以(now - startTime <= 5)满足,继续进入while循环,然后阻塞在recv上,recv设置的超时是1秒,那么其实最后跳出while循环的时间距离第一次recv已经过去了5.99秒。暂时没想到什么好办法,因为把recv设置成理解返回的话,while循环的次数太多,效率也不高。所以最好是要有一种通知的机制。

  • CGI Server

    CGI Server一般是要fork一个进程来执行http request的URI中指定的CGI Script的,并且通过环境变量,向CGI Script传递本次请求的信息,具体怎么做可以看看这篇文章。但是注意到paekdusan是一个多线程的服务器,所以这里涉及到多线程和多进程,这是个很蛋疼的情况。多线程和多进程的混合会有很多问题,这篇文章有详细的介绍,好吧,你可能会发现它被墙了,那我还是简单的介绍一下会有什么问题吧。

    首先需要说明的是,在一个子线程中调用fork会发生什么:产生的子进程中只会有一个线程,也就是调用fork的这个线程。

    那么问题来了,假如父进程中的其他线程获取了一个锁,正在改线程间共享的数据,这时共享数据处于半修改状态。但是在子进程中,其他线程都消失了,那这些共享数据的修改怎么办?并且,锁的状态也得未定义了。另外,即使你的代码是线程安全的,你也不能保证你用的Lib的实现是线程安全的。

    所以唯一合理的在多线程的环境下使用多进程的情况,只有fork之后立即exec,也就是马上讲子进程替换成一个新的程序,这样的话,子进程中所有的数据都变得不重要,都抛弃了。所以,其实多线程的CGI Server也算是合理,但是需要注意安全性问题。因为打开的子进程默认是继承了父进程的文件描述符的,也就是说,子进程可以有父进程对文件的读写权限。

    我大概知道的就这么多,更详细的还是*去读原文吧。

  • C++11的thread

    C++11的thread用起来感觉比以前的linux上的pthread或者是windows上的beginthread都好用太多来,来一段简短的代码展示一下基本用法吧。

    void sayWord(const string& word) {     for (int i = 0; i < 1000; i++) {         cout << word << endl;     } } void saySentence(const string& sentence) {     for (int i = 0; i < 1000; i++) {         cout << sentence << endl;     } }  int main() {     string word = "hello";     string sentence = "this is an example from cstdlib.com";     thread t1(std::bind(sayWord, ref(word)));     thread t2(saySentence, ref(sentence));      t1.join();     t2.join();     return 0; } 

    运行以上代码,会发现交替输出“hello”和“this is an example from cstdlib.com”。注意到t1和t2的构造参数看起来怪怪的,“std::bind(sayWord, ref(word))”和“saySentence, ref(sentence)”,主要线程函数的参数是引用,有个模版里面的bind在这,我也很难解释清楚,感觉模版叼叼的。另外,以非静态类成员函数创建线程时,需要在参数中带上this或者是ref一个对象的实例,不然无法调用。

  • C++11的mutex和lock

    注意到上面thread的代码其实是有问题的,两个线程交替输出的东西可能会混合,所以要加锁。C++11的mutex和lock也很好用。

    代码里面用的是lock_guard,lock_guard就是在构造函数里面调用mutex的lock方法,析构函数里面调用mutex的unlock方法,用起来比较方便。unique_lock和lock_guard类似,但是多了一些其他的成员函数来配合其他的mutex类。关于mutex和lock的用法,[这篇博客](http://www.cnblogs.com/haippy/p/3237213.html)说的比较详细。主要和pthread里面的lock的区别就是,在pthread中,重复获取一个已经获得的lock不会报错,而在C++11中会报错。

  • C++11的condition_variable

    在paekdusan的task队列是BoundedBlockingQueue,也就是说有阻塞和唤醒的操作。所以涉及到condition_variable。condition_variable主要用两个函数:wait(unique_lock<mutex>& lck)notify_one()。线程被wait阻塞时,会先调用lck.unlock()函数释放锁;线程被notify_one唤醒时,会调用lck.lock()获取锁,以回复当时wait前的样子。关于condition_variable的用法,这篇博客说的比较详细

  • windows和linux上socket的API的不同点
    1. windows上需包含winsock.h;linux上需包含cerrno,sys/socket.h,sys/types.h,arpa/inet.h和unistd.h
    2. windows上调用socket之前要调用WSAStartup,并且用#pragma comment(lib,”Ws2_32”)链接Ws2_32.lib
    3. windows上关闭socket的函数叫做closesocket;linux上叫做close
    4. windows上获取错误码用GetLastError();linux上查看全局变量errno,错误码的意义也不一样
    5. windows上设置SO_RCVTIMEO和SO_SNDTIMEO选项时,单位是毫秒;linux是秒
    6. windows上accept的原型是accept(SOCKET, struct sockaddr, int);linux上accept的原型是accept(int, struct sockaddr, socklen_t)

    我遇到的就这些,估计还有很多,只是我还没遇到。