标签 wifidog分析 下的文章

wifidog HTTP Lighttpd1.4.20源码分析之buffer.c(h)--------字符串内存管理(2)

一些工具性的函数:
1、int LI_ltostr(char *buf, long val);
将长整型val转化成字符串,并存入buf中。

Code
int LI_ltostr(char *buf, long val) 
{
    char swap;
    char *end;
    int len = 1;
    //val为负数,加一个负号,然后转化成正数
    if (val < 0) 
    {
        len++;
        *(buf++) = '-';
        val = -val;
    }
    end = buf;
    /*
          这里val必须设置为大于9,并在循环外在做一次转换
            (*(end) = '0' + val)!
             因为如果val设置为大于0,当val为0时,将不进入循环,那么循
           环后面直接在buf中
     * 追加'\0'。这样0就被转化成了空串!!
     * 这里val转化后的字符串是逆序存放在buf中的,在后面要反转,
     * 以得到正确的顺序。
     */
    while (val > 9) 
    {
        *(end++) = '0' + (val % 10);
        val = val / 10;
    }
    *(end) = '0' + val;
    *(end + 1) = '\0';
    len += end - buf;
    //将字符串反转,
    while (buf < end) 
    {
        swap = *end;
        *end = *buf;
        *buf = swap;
        buf++;
        end--;
    }
    return len;
}

2、char hex2int(unsigned char c);
  converts hex char (0-9, A-Z, a-z) to decimal.returns 0xFF on
invalid input. 将16进制的字符转化成对应的数字,非法输入返回0xFF。忽略c的大小写。
3、char int2hex(char i);
  将i转化成对应的16进制形式
4、int light_isdigit(int c);
  c是否是数字。0-9
5、int light_isxdigit(int c);
  c是否是十六进制的数字0-9 a-f
6、int light_isalpha(int c);
  c是否是字母。
7、int light_isalnum(int c);
  c是否是字母或数字。

  以上几个函数在处理大小写的时候,都使用了c |= 32;将c转换成小写的形式,无论c原来是大写还是小写。原理在函数buffer_caseless_compare中讲解过。
8、int buffer_to_lower(buffer * b);
  将b中的数据转换成小写。
9、int buffer_to_upper(buffer * b);
  将b中的数据转换成大写。
  以上两个函数没有在buffer.c中定义。

  下面的几个宏定义一些方便的操作。

Code
#define BUFFER_APPEND_STRING_CONST(x, y) \
    buffer_append_string_len(x, y, sizeof(y) - 1)

#define BUFFER_COPY_STRING_CONST(x, y) \
    buffer_copy_string_len(x, y, sizeof(y) - 1)
//在buffer中追加一个‘/’,如果最后一个字符是‘/’,则不追加。
#define BUFFER_APPEND_SLASH(x) \
    if (x->used > 1 && x->ptr[x->used - 2] != '/') 
{ BUFFER_APPEND_STRING_CONST(x, "/"); }

#define CONST_STR_LEN(x)  x, x ? sizeof(x) - 1 : 0
#define CONST_BUF_LEN(x)  x->ptr, x->used ? x->used - 1 : 0

#define SEGFAULT() 
do { 
fprintf(stderr, "%s.%d: aborted\n", __FILE__, __LINE__); abort(); 
} while(0)
#define

以下的函数操作涉及到编码问题。在lighttpd中,使用到的编码有六种。具体的类型定义在下面的结构体中。

Code
typedef enum 
{
    ENCODING_UNSET,
    ENCODING_REL_URI,                /* for coding a rel-uri (/withspace/and%percent) nicely as part of a href */
    ENCODING_REL_URI_PART,        /* same as ENC_REL_URL plus coding / too as %2F */
    ENCODING_HTML,                /* & becomes &amp; and so on */
    ENCODING_MINIMAL_XML,        /* minimal encoding for xml */
    ENCODING_HEX,                    /* encode string as hex */
    ENCODING_HTTP_HEADER            /* encode \n with \t\n */

于此对应的 buffer.c 源文件中给出了
const char encoded_chars_rel_uri_part[]
const char encoded_chars_rel_uri[]
const char encoded_chars_html[]
const char encoded_chars_minimal_xml[]
const char encoded_chars_hex[]
const char encoded_chars_http_header[]
六个标志数组,数组中值为 1 的元素表示对应下标值大小的字符需要被编码转换,否则不需要转换可以直接使用(即编码前和编码后是同一个值)。例如对于 encoded_chars_rel_uri数组,encoded_chars_rel_uri[32]值为1表示该对应的字符(32对应的是空格,因为空格的十进制值为 32)需要被 uri 编码(被编码为“%20”),而对于值为 0的 encoded_chars_rel_uri[48],其对应的字符就不需要编码(48 对应的是字符‘0’,而字符‘0’并不是特殊字符,因此不用编码。)。对于具体的编码方式,请查阅相关资料。
1、int buffer_append_string_encoded(buffer * b, const char *s,size_t s_len, buffer_encoding_t encoding);
  将字符串s以指定的编码方式存入b中。encoding指定编码的方式。

/**
    * 将字符串s以指定的编码方式存入b中。
    * encoding指定编码的方式。
    */
   int buffer_append_string_encoded(buffer *b, const char *s, size_t s_len, buffer_encoding_t encoding) 
   {
       unsigned char *ds, *d;
       size_t d_len, ndx;
       const char *map = NULL;

      if (!s || !b) return -1;

      //b中存放的不是亦'\0'结尾的字符串。报错。
      if (b->ptr[b->used - 1] != '\0') 
      {
          SEGFAULT();
      }

      if (s_len == 0) return 0;

      //根据编码方式,选择对应的编码数组,就是上面的那六个数组。
      switch(encoding) {
      case ENCODING_REL_URI:
          map = encoded_chars_rel_uri;
          break;
      case ENCODING_REL_URI_PART:
          map = encoded_chars_rel_uri_part;
          break;
      case ENCODING_HTML:
          map = encoded_chars_html;
          break;
      case ENCODING_MINIMAL_XML:
          map = encoded_chars_minimal_xml;
          break;
      case ENCODING_HEX:
          map = encoded_chars_hex;
          break;
      case ENCODING_HTTP_HEADER:
          map = encoded_chars_http_header;
          break;
      case ENCODING_UNSET:
          break;
      }

      assert(map != NULL);

      /* 
       * count to-be-encoded-characters 
       * 计算经过编码转换后的字符串s的长度。
       * 不同的编码方式,对与不同的字符,其转换后的字符长度不同。
       */
      for (ds = (unsigned char *)s, d_len = 0, ndx = 0; ndx < s_len; ds++, ndx++) 
      {
         if (map[*ds]) 
          {
              switch(encoding) 
              {
              case ENCODING_REL_URI:
              case ENCODING_REL_URI_PART:
                  d_len += 3;
                  break;
             case ENCODING_HTML:
             case ENCODING_MINIMAL_XML:
                  d_len += 6;
                  break;
              case ENCODING_HTTP_HEADER:
              case ENCODING_HEX:
                  d_len += 2;
                  break;
              case ENCODING_UNSET:
                  break;
              }
          } 
          else //字符不需要转换 
          {
              d_len ++;
          }
      }

      buffer_prepare_append(b, d_len);

      //下面这个循环就是开始做实际的编码转换工作。
     //ds指向字符串s中的字符。d指向b的数据去存放字符的位置。
      for (ds = (unsigned char *)s, d = (unsigned char *)b->ptr + b->used - 1, d_len = 0, ndx = 0; ndx < s_len; ds++, ndx++) 
      {
         if (map[*ds]) 
          {
              switch(encoding) 
              {
              case ENCODING_REL_URI:             //此编码不需要转换
              case ENCODING_REL_URI_PART:     //将字符ASCII码转化成其对应的十六进制的形式,并在前面加上'%'
                  d[d_len++] = '%';
                  d[d_len++] = hex_chars[((*ds) >> 4) & 0x0F];
                  d[d_len++] = hex_chars[(*ds) & 0x0F];
                  break;
              case ENCODING_HTML:             //不需要转换
              case ENCODING_MINIMAL_XML:         //也是转换成ASCII编码的十六进制形式,前面要加上"&#x",尾随一个';'
                  d[d_len++] = '&';
                  d[d_len++] = '#';
                 d[d_len++] = 'x';
                 d[d_len++] = hex_chars[((*ds) >> 4) & 0x0F];
                 d[d_len++] = hex_chars[(*ds) & 0x0F];
                 d[d_len++] = ';';
                 break;
             case ENCODING_HEX:                 //直接转换成ASCII码对应的十六进制。
                 d[d_len++] = hex_chars[((*ds) >> 4) & 0x0F];
                 d[d_len++] = hex_chars[(*ds) & 0x0F];
                 break;
             case ENCODING_HTTP_HEADER:        //这个处理HTTP头中的换行,统一转换成'\n\t'
                 d[d_len++] = *ds;
                 d[d_len++] = '\t';
                 break;
             case ENCODING_UNSET:
                 break;
             }
        } 
         else 
         {
             d[d_len++] = *ds;
         }
     }     
     /* 
      * terminate buffer and calculate new length 
      * 在新字符串尾部加上一个'\0' 
     */
     b->ptr[b->used + d_len - 1] = '\0';     
     b->used += d_len;         //新的字符串长度。
     return 0;
 }

2、static int buffer_urldecode_internal(buffer *url, int is_query)
  将rul中存放的特殊编码的字符转换成正常的字符。这里的编码是指上面六种编码中的ENCODING_REL_RUL_PART.

/* 
   * decodes url-special-chars inplace.
   * replaces non-printable characters with '_'
   * 将rul中存放的特殊编码的字符转换成正常的字符。这里的编码是指上面六种编码中的ENCODING_REL_RUL_PART.
   * 也就是把ASCII码的16进制表示,转换成正常的ASCII码。转换后的结果直接存放在url中。
   *
   * 这个is_query参数的作用仅仅控制是否将字符串中的'+'转换成空格' '。
   */

 static int buffer_urldecode_internal(buffer *url, int is_query) 
 {
     unsigned char high, low;
     const char *src;
     char *dst;

     if (!url || !url->ptr) return -1;

     //源字符串和目的字符串是同一个串。
     src = (const char*) url->ptr;
     dst = (char*) url->ptr;

     while ((*src) != '\0') 
     {
         if (is_query && *src == '+') 
         {
             *dst = ' ';
         } 
         else if (*src == '%') 
         {
             *dst = '%';
             //将后面16进制表示的ASCII码转换成正常的ASCII码。
             high = hex2int(*(src + 1));          //高四位
             if (high != 0xFF)                   //0xFF表示转换出错。
             {
                 low = hex2int(*(src + 2));         //低四位
                 if (low != 0xFF) 
                 {
                     high = (high << 4) | low;      //合并
                     /* map control-characters out  判断是否是控制字符。*/
                    if (high < 32 || high == 127) 
                         high = '_';
                     *dst = high;
                     src += 2;     
                     //这个转换过程中,三个源字符转换成一个目的字符。
                    //虽然是一个字符串,但源字符串遍历的更快,不会冲突。
                 }
             }
         } 
         else 
         {
             *dst = *src;
         }

         dst++;
        src++;
     }

     *dst = '\0';     //新结尾。
     url->used = (dst - url->ptr) + 1;

     return 0;
 }

3、int buffer_path_simplify(buffer * dest, buffer * src);
  删除路径字符串中的"/../","//"和"/./",简化路径,并不是简单的删除。

/* Remove "/../", "//", "/./" parts from path.
    *
    * /blah/..         gets  /
    * /blah/../foo     gets  /foo
    * /abc/./xyz       gets  /abc/xyz
    * /abc//xyz        gets  /abc/xyz
    *
    * NOTE: src and dest can point to the same buffer, in which case,
    *       the operation is performed in-place.
   *
   * 删除路径字符串中的"/../","//"和"/./",简化路径,并不是简单的删除。
   * 对于"/../"在路径中相当与父目录,因此,实际的路径相当于删除"/../"和其前面的一个"/XX/".
   * 如: /home/test/../foo   ->   /home/foo
   * 而"//"和"/./"表示当前目录,简单的将其删去就可以了。
  * NOTE: 源缓冲src和目的缓冲可以指向同一个缓冲,在这种情况下,操作将源缓冲中的数据替换。
   */

  int buffer_path_simplify(buffer *dest, buffer *src)
  {
      int toklen;
      char c, pre1;
      char *start, *slash, *walk, *out;
      unsigned short pre;     //pre两个字节,char一个字节,pre中可以存放两个字符。

     if (src == NULL || src->ptr == NULL || dest == NULL)
          return -1;

      if (src == dest)
          buffer_prepare_append(dest, 1);
      else
          buffer_prepare_copy(dest, src->used + 1);

      walk  = src->ptr;
      start = dest->ptr;
      out   = dest->ptr;
      slash = dest->ptr;


  #if defined(__WIN32) || defined(__CYGWIN__)
      /* 
       * cygwin is treating \ and / the same, so we have to that too
       * cygwin中\和/相同。转化之。
       */

      for (walk = src->ptr; *walk; walk++) 
      {
          if (*walk == '\\') *walk = '/';
      }
      walk = src->ptr;
  #endif
      //过滤掉开始的空格。
      while (*walk == ' ') 
      {
          walk++;
      }

      pre1 = *(walk++);
      c    = *(walk++);
      pre  = pre1;
      if (pre1 != '/')  //路径不是以'/'开始,在目的路径中加上'/'
      {
          pre = ('/' << 8) | pre1; //将prel指向的字符存放在pre的高八位。
         *(out++) = '/';
      }
      *(out++) = pre1;

     if (pre1 == '\0')          //转换结束
      {
          dest->used = (out - start) + 1;
          return 0;
      }

      while (1) 
      {
          if (c == '/' || c == '\0') 
          {
              toklen = out - slash; //slash指向距离c指向的字符前面最近的一个'/'。
              if (toklen == 3 && pre == (('.' << 8) | '.')) // "/../"
             {
                 out = slash;
                 if (out > start) //删除"/../"前面的一层目录"/XX/".
                  {
                      out--;
                     while (out > start && *out != '/') 
                      {
                          out--;
                      }
                  }

                  if (c == '\0')
                      out++;
              } 
              else if (toklen == 1 || pre == (('/' << 8) | '.')) // "//" 和 "/./"
              {
                  out = slash;
                 if (c == '\0')
                      out++;
              }

             slash = out;
         }

         if (c == '\0')
             break;

         pre1 = c;
         pre  = (pre << 8) | pre1; //pre始终存放的是prel指向的字符和其前一个字符。
         c    = *walk;
         *out = pre1;

         out++;
         walk++;
     }

     *out = '\0';
     dest->used = (out - start) + 1;

     return 0;
 }

总得来说,buffer的内容比较简单,其他的函数读者可以自行查看。

本文章由 http://www.wifidog.pro/2015/04/15/wifidog%E8%AE%A4%E8%AF%81lighttpd%E5%AD%97%E7%AC%A6%E4%B8%B2%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86-2.html 整理编辑,转载请注明出处

wifidog自带HTTP 服务器 Lighttpd1.4.20源码分析之array.c(h) -----通用数组(1)

Lighttpd提供了一个通用数组,这个数组与程序的其他部分练习较少,因此可以单独进行分析。
首先要说一下Lighttpd中的定义的一些数据结构。
在array.h中有下面的定义:

Code
typedef enum { 
        TYPE_UNSET,         /* 数据的类型未设置,
                               这几种数据类型使用了面向对象的设计思想,
                               这个类型相当于父类型,继承关系见后面 
                             */
        TYPE_STRING,         /* 字符串类型 */
        TYPE_COUNT,         /* COUNT类型 */
        TYPE_ARRAY,         /* 数组类型 */
        TYPE_INTEGER,     /* 整数类型 */
        TYPE_FASTCGI,     /* FASTCGI类型 */
        TYPE_CONFIG         /* CONFIG类型 */
} data_type_t;

这是一个枚举类型,定义了各个数据类型的标志。从中可以看出程序中所定义使用的数据类型的种类和个数。
Lighttpd在定义数据类型的时候使用了面向对象的思想,因此,程序具有很好的扩展性和适应性。这些类型中,最重要的是UNSET类型,这个类型在所有的数据类型中,起到了父类型的作用。在array.h中,UNSET类型的定义如下:

Code
#define DATA_UNSET \
    data_type_t type; \
    buffer *key; \
    int is_index_key; /* 1 if key is a array index */ \
    struct data_unset *(*copy)(const struct data_unset *src); \
    void (* free)(struct data_unset *p); \
    void (* reset)(struct data_unset *p); \
        int (*insert_dup)(struct data_unset *dst, struct data_unset *src); \
    void (*print)(const struct data_unset *p, int depth)

typedef struct data_unset {
    DATA_UNSET;
} data_unset;

其中,UNSET类型数据的定义中,数据的实际定义部分使用宏DATA_UNSET,这样可以方便其他类型在定义中直接引用DATA_UNSET宏来模拟继承。在宏DATA_UNSET中,定义了下面五个函数指针:

Code
struct data_unset *(*copy)(const struct data_unset *src); 
void (* free)(struct data_unset *p); 
void (* reset)(struct data_unset *p); 
int (*insert_dup)(struct data_unset *dst, struct data_unset *src); 
void (*print)(const struct data_unset *p, int depth)

这五个函数指针相当于UNSET的成员函数,其他类型可以通过对这五个指针赋值来实现成员函数的重写(Overwrite)。每种类型都配有自己特有的初始化函数,形式为:data_XXXXX *data_XXXXX_init(void)。在这些初始化函数中,对上面这五个函数指针进行赋值,当然,赋值的函数都应先定义好。
这几种类型的继承关系图如下:(类图)

wifidog libhttpd源码分析.jpg

下面分析一下STRING类型的初始化函数data_string * data_string_init(void):

Code
data_string *data_string_init(void)
{
    data_string *ds;
    /*
分配内存空间。
这里用的是calloc函数,分配的空间会自动清零。
*/
    ds = calloc(1, sizeof(*ds));
    assert(ds);
    /*
初始化各个数据成员,
这里调用buffer_init函数,主要就是分配内存空间
*/
    ds->key = buffer_init();
    ds->value = buffer_init();
    /*确定成员函数的具体调用函数,对函数指针赋值*/
    ds->copy = data_string_copy;
    ds->free = data_string_free;
    ds->reset = data_string_reset;
    ds->insert_dup = data_string_insert_dup;
    ds->print = data_string_print;
    ds->type = TYPE_STRING;
    return ds;
}

其他类型的init函数,以及其他函数都不难,读者可自行查看代码。
至于各个类型的用处以及各个类型中个成员变量的含义,暂且不用关心,只要知道这七个类型之间的关系即可,除了UNSET类型,其他类型的操作函数的实现都在文件data_XXXXX.c中。这些函数的实现都很简单,不在一一介绍,读者可自己看看。这七个类型构成了通用数组所要处理的类型,其中,在数组的定义和实现中只使用UNSET类型,利用上面的定义,通用数组可以不用关心数组中存储的到底是哪种具体的类型,只需将其按照UNSET类型来处理就可以了。这就实现了通用数组。
下面这个定义是通用数组的核心定义,也就是定义了数组。。。

Code
typedef struct 
{
    /* UNSET类型的指针型数组,存放数组中的元素 */
    data_unset **data;
    /* 存放着排好序的各个元素的下标的数组 */
    size_t *sorted;
    size_t used;    /* data中使用了的长度,也就是数组中元素个数 */

        /* data的大小。data的大小会根据数据的多少变化,会为以后的数据预先分
           配空间 */
    size_t size;    

        size_t unique_ndx;        /*  */
        /* 比used大的最小的2的倍数。也就是离used最近的且比used大的2的倍
              数 ,用于在数组中利用二分法查找元素*/
    size_t next_power_of_2;
        /* data is weakref, don't bother the data */
        /* data就是一个指针,不用关系其所指向的内容 */
    int is_weakref;                
} array;

各个变量的含义见上。
array.h中还有一个定义:

typedef struct {
  DATA_UNSET;
  array *value;
} data_array;

本文章由 http://www.wifidog.pro/2015/04/13/wifidog-lighttpd%E5%88%86%E6%9E%90%E9%80%9A%E7%94%A8%E6%95%B0%E7%BB%84-1.html 整理编辑,转载请注明出处

wifidog自带http服务器wiLighttpd1.4.20源码分析之状态机(4) 错误处理和连接关闭

Lighttpd所要处理的错误分为两种。一种是http协议规定的错误,如404错误。另一种就是服务器运行过程中的错误,如write错误。

  对于http协议规定的错误,lighttpd返回相应的错误提示文件。其实对于lighttpd而言,这不算错误。在返回错误提示文件后,相当于顺利的完成了一次请求,只是结果和客户端想要的不一样而已。

对于服务器运行中的错误,状态机会直接进入CON_STATE_ERROR状态。大部分的情况下,这种错误都是由客户端提前断开连接所造成的。比如你不停的刷新页面,在你刷新的时候,前一次的连接没有完成,但被浏览器强行断开,这时,服务器就会出现连接错误。对于服务器而言,刷新前后的两个连接是不相干的。因此,服务器在接收后一个连接的时候仍然会继续处理前一次的连接。而这时前一次的连接已经断开,这就产生了连接错误。   

进入CON_STATE_ERROR状态后,如果前面的处理已经得到了结果。也就是http_status不为空。那么调用plugins_call_handle_request_done告诉插件请求处理结束。

  /*
  * even if the connection was drop we still have to write it to the
  * access log
  */
   if (con->http_status)
   {
        plugins_call_handle_request_done(srv, con);
   }

接着,如果使用了ssl,关闭ssl连接。关闭ssl连接的代码很长,但大部分都是错误处理。再朝后,如果连接模式不是DIRECT,调用plugins_call_handle_connection_close告诉插件连接已经关闭。到此,如果连接没有设置keep_alive,那么关闭连接并做一些清理工作之后就直接结束状态机的运行了。
如果设置了keep_alive,此时可能是服务器首先关闭连接的。调用shutdown关闭连接的读和写。如果关闭没有出错,状态机进入CON_STATE_CLOSE状态。

   /*
    * close the connection
    */
   if ((con->keep_alive == 1) && (0 == shutdown(con->fd, SHUT_WR)))
   {
       con->close_timeout_ts = srv->cur_ts;
       connection_set_state(srv, con, CON_STATE_CLOSE);、
       if (srv->srvconf.log_state_handling)
       {
           log_error_write(srv, __FILE__, __LINE__, "sd",
                           "shutdown for fd", con->fd);
       }
   }

上面的代码中有这么一句:con->close_timeout_ts = srv->cur_ts;将close_timeout_ts的值设置为当前时间。这时干吗用的?不着急,继续完后走。
进入CON_STATE_ERROR状态之后,如果是keep_alive,且缓冲区中有数据还没读,那么把这些数据读出来然后直接丢弃。如果没有数据可读,直接设置close_time_ts为0。接着执行下面的代码:

  if (srv->cur_ts - con->close_timeout_ts > 1)
   {
       connection_close(srv, con);
       if (srv->srvconf.log_state_handling)
       {
           log_error_write(srv, __FILE__, __LINE__, "sd", "connection closed for fd", con->fd);
       }
   }

除了输出日志,这段代码就是调用了connection_close。connection_close做最后的清理工作,包括调用close,将对应的connection放回缓冲池中等。前面刚刚说过,在CON_STATE_ERROR中设置了close_time_ts为cur_ts。在出了CON_STATE_ERROR后,进入CON_STATE_CLOSE,这段时间cur_ts是没有改变的。如果前面的代码中测试缓冲区中没有数据可读,此时const_time_ts是等于cur_ts。也就是说状态机还在CON_CLOSE_STATE这个状态,然后就退出了状态机的大while循环。服务器进入了connection_state_mechine最后面的那个switch语句。在这个switch中,连接对应的fd被加入到fdevent系统中并监听读入事件。
这个时候连接都已经关闭了还有什么能读的啊?别急!细心的读者应该注意到了,到这个时候,服务器仅仅是对连接调用了shutdown函数,没有调用close函数。首先说一下shutdown和close的区别。close作用在socket fd上和作用在其他fd上的效果差不多,都是减少引用计数,当计数为0的时候释放资源,关闭连接。shutdown函数则是针对socket fd的专门函数。shutdown可以关闭socket连接的一个方向,也就是可以只关闭写或者只关闭读(socket连接是全双工的)。另外一个区别就是,如果连接是多个进程共享的,那么在一个进程中调用close不影响其他进程使用连接,因为仅仅是引用计数减少1。而如果一个进程调用了shutdown ,那么,不管三七二十一,系统直接咔嚓掉这个连接,其他进程看到的也是关闭的连接。还有一个区别,调用了close的socket fd,read,write函数不能再从这个fd上读取或发送数据。而调用了shutdown的socket fd,如果缓冲区中还有数据可读,由于此时对于进程而言,socket fd没有关闭,read依然可以从这个fd读数据。由于shutdown仅仅是关闭了连接,不会进行资源的释放,要想释放连接占用的资源,还必须调用close函数。
对于keep_alive的连接,关闭是服务器主动发起的。根据TCP协议,主动发起关闭的一方,其连接将进入TIME_WAIT状态,此时连接所占用的资源没有释放。更悲剧的是要在这个状态待很长时间。。。(默认4分钟)对于高并发的服务器,如果服务器主动关闭大量连接,那么服务器的资源很快就会被用光(端口,内存等),新的连接将无法建立。关于这个TIME_WAIT状态,读者可自行google之,网上有很多介绍的文章以及处理办法。虽然这个TIME_WAIT状态看似会给我们带来很多麻烦,但是,如果没有这个状态我们会更麻烦。。。《UNIX Network Programming Volum1》这本神作中有详细的介绍,有兴趣的读者可以看看。既然麻烦不可避免,那么就尽量将麻烦的影响见到最低。连接占用的资源主要就是端口和内存。端口是没办法的,占用就占用了。但是,内存还是可以节省一点的。前面说了,shutdown之后,我们依然可以把缓冲区的数据读出来。那么,我们把这些数据读出来以后,缓冲区所占用的内存就可以释放了。从而降低了内存的使用。
在CON_STATE_CLOSE中,下面的代码把缓冲区的数据读了出来:

  if (ioctl(con->fd, FIONREAD, &b))
  {
      log_error_write(srv, __FILE__, __LINE__, "ss", "ioctl() failed", strerror(errno));
  }
   if (b > 0)
  {
      char buf[1024];
      log_error_write(srv, __FILE__, __LINE__, "sdd", "CLOSE-read()", con->fd, b);

     read(con->fd, buf, sizeof(buf));
  }
else
   {
       /*
        * nothing to read
        */

     con->close_timeout_ts = 0;
  }

如果没有数据可读,那么设置close_timeout_ts会使连接在后面的代码中被关闭。如果有数据可读,读取数据之后,连接依然处在CON_STATE_CLOSE状态中,连接对应的fd被加入到fdevent系统中监听读事件。如果缓冲区中还有数据,那么在connection_handle_fdevent 函数中,也有上面这段代码,再次运行之。如果数据没有读完,服务器将会重复的在connection_handle_fdevent函数中运行上述代码直到数据读完。随着close_timeout_ts被设置为0,在下次joblist的调度中,状态机将会关闭连接,清理所有资源。
至此,连接正式关闭。之所以这么麻烦,就是由于连接是服务器主动关闭的,会有TIME_WAIT状态的问题。这样处理仅仅在内存上有了一些节省。但是具体效果怎样,这要看系统内核是如何处理连接缓冲区的。如果各位读者了解这方面的内容,还请不吝赐教!
另外,shutdown之后内核中的缓冲区到底会怎样笔者并不是很确定。上面的内容只是根据代码的推断。还是那句话,如果给为读者有什么高见,还行不吝赐教啊。

本文章由 http://www.wifidog.pro/2015/04/13/wifidog-lighttpd-1.html 整理编辑,转载请注明出处

wifidog认证自带http服务器Lighttpd1.4.20源码分析之状态机(3)返回response

好久没顾这个了,最近比较清闲,重新拾掇一下,有始有终。
  回到正题,前一篇介绍完了请求的处理,先面lighttpd将会把处理的结果返回给客户端。状态机进入CON_STATE_RESPONST_START。在这个状态中,服务器主要的工作在函数connection_handle_write_prepare。这个函数不算复杂,主要是根据客户端请求的method来设置response的headers,其实就是设置“Content-Length”的值。下面是函数代码,做了一些删减:

static int connection_handle_write_prepare(server * srv, connection * con)
{
   if (con->mode == DIRECT)
   {
       /*
        * static files
        */
       switch (con->request.http_method)
       {
       case HTTP_METHOD_GET:
       case HTTP_METHOD_POST:
       case HTTP_METHOD_HEAD:
       case HTTP_METHOD_PUT:
       case HTTP_METHOD_MKCOL:
       case HTTP_METHOD_DELETE:
       case HTTP_METHOD_COPY:
       case HTTP_METHOD_MOVE:
       case HTTP_METHOD_PROPFIND:
       case HTTP_METHOD_PROPPATCH:
       case HTTP_METHOD_LOCK:
       case HTTP_METHOD_UNLOCK:
           break;
       case HTTP_METHOD_OPTIONS:
           /*
            * 400 is coming from the request-parser BEFORE uri.path is set
            * 403 is from the response handler when noone else catched it
            * */
           if ((!con->http_status || con->http_status == 200)
               && con->uri.path->used && con->uri.path->ptr[0] != '*')
           {
               response_header_insert(srv, con, CONST_STR_LEN("Allow"),
                  CONST_STR_LEN("OPTIONS, GET, HEAD, POST"));

               con->response.transfer_encoding &= ~HTTP_TRANSFER_ENCODING_CHUNKED;
               con->parsed_response &= ~HTTP_CONTENT_LENGTH;

               con->http_status = 200;
               con->file_finished = 1;

               chunkqueue_reset(con->write_queue);
           }
           break;
       default:
           switch (con->http_status)
           {
           case 400:            /* bad request */
           case 414:            /* overload request header */
           case 505:            /* unknown protocol */
           case 207:            /* this was webdav */
               break;
           default:
               con->http_status = 501;
               break;
           }
           break;
       }
   }

   if (con->http_status == 0)
   {
       con->http_status = 403;
   }

   switch (con->http_status)
   {
   case 204:                    /* class: header only */
   case 205:
   case 304:
       /*
        * disable chunked encoding again as we have no body
        */
       con->response.transfer_encoding &= ~HTTP_TRANSFER_ENCODING_CHUNKED;
       con->parsed_response &= ~HTTP_CONTENT_LENGTH;
       chunkqueue_reset(con->write_queue);

       con->file_finished = 1;
       break;
   default:                    /* class: header + body */
       if (con->mode != DIRECT)
           break;

       /*
        * only custom body for 4xx and 5xx
        */
       if (con->http_status < 400 || con->http_status >= 600)
           break;

       con->file_finished = 0;
       buffer_reset(con->physical.path);

       /*
        * try to send static errorfile
        */
       if (!buffer_is_empty(con->conf.errorfile_prefix))
       {
        //设置对应的错误提示文件
       }

       if (!con->file_finished)
       {
           //没有对应的错误提示文件,设置默认错误提示。
       }
       break;
   }

   if (con->file_finished)
   {
       /*
        * we have all the content and chunked encoding is not used, set a
        * content-length
        */
       if ((!(con->parsed_response & HTTP_CONTENT_LENGTH)) &&
           (con->response.transfer_encoding & HTTP_TRANSFER_ENCODING_CHUNKED) == 0)
       {
           off_t qlen = chunkqueue_length(con->write_queue);
           /**
            * The Content-Length header only can be sent if we have content:
            * - HEAD doesn't have a content-body (but have a content-length)
            * - 1xx, 204 and 304 don't have a content-body (RFC 2616 Section 4.3)
            *
            * Otherwise generate a Content-Length header as chunked encoding is not
            * available
            */
           if ((con->http_status >= 100 && con->http_status < 200) ||
               con->http_status == 204 || con->http_status == 304)
           {
               data_string *ds;
               /*
                * no Content-Body, no Content-Length
                */
               if (NULL != (ds = (data_string *) array_get_element(con->response.headers, "Content-Length")))
               {
                   buffer_reset(ds->value);    /* Headers with empty values
                                                * are ignored for output */
               }
           }
           else if (qlen > 0 || con->request.http_method != HTTP_METHOD_HEAD)
           {
               /*
                * qlen = 0 is important for Redirects (301, ...) as they MAY
                * have a content. Browsers are waiting for a Content otherwise
                */
               buffer_copy_off_t(srv->tmp_buf, qlen);

               response_header_overwrite(srv, con, CONST_STR_LEN("Content-Length"), CONST_BUF_LEN(srv->tmp_buf));
           }
       }
   }
   else
   {
       /**
        * the file isn't finished yet, but we have all headers
        *
        * to get keep-alive we either need:
        * - Content-Length: ... (HTTP/1.0 and HTTP/1.0) or
        * - Transfer-Encoding: chunked (HTTP/1.1)
        */

       if (((con->parsed_response & HTTP_CONTENT_LENGTH) == 0) &&
           ((con->response.transfer_encoding & HTTP_TRANSFER_ENCODING_CHUNKED) == 0))
       {
           con->keep_alive = 0;
       }

       /**
        * if the backend sent a Connection: close, follow the wish
        *
        * NOTE: if the backend sent Connection: Keep-Alive, but no Content-Length, we
        * will close the connection. That's fine. We can always decide the close
        * the connection
        *
        * FIXME: to be nice we should remove the Connection: ...
        */
       if (con->parsed_response & HTTP_CONNECTION)
       {
           /*
            * a subrequest disable keep-alive although the client wanted it
            */
           if (con->keep_alive && !con->response.keep_alive)
           {
               con->keep_alive = 0;
           }
       }
   }

   if (con->request.http_method == HTTP_METHOD_HEAD)
   {
       /**
        * a HEAD request has the same as a GET
        * without the content
        */
       con->file_finished = 1;

       chunkqueue_reset(con->write_queue);
       con->response.transfer_encoding &= ~HTTP_TRANSFER_ENCODING_CHUNKED;
   }

   http_response_write_header(srv, con);

   return 0;
}

首先,该函数判断连接的模式(mode)是否是DIRECT,如果是,说明连接没有经过插件处理,是由服务器自身处理的。这里判断连接的请求method,如果是OPTION,则设置Allow的值。同时清空write_queue,因为没有数据需要返回。 接着,在下面这个switch语句中,比较http_status的值,如果为204,205,304,说明服务器不需要给客户端返回文件,仅仅返回 response中headers及其之前的部分。这里和前面处理OPTION方法都设置con->file_finished为1。 file_finished用来标记客户端请求的静态文件是否已经发送完了(这个file_finished的含义比较模糊,目前还没搞清楚是表示文件发 送完毕,还是要发送的文件设置完毕可以发送。。。也有可能是个bug。。。如果各位读者有什么高见,还望不吝赐教!)。这两处都不需要给客户端发送文件, 因此将其设置为1,发送程序将直接跳过文件的发送。switch的default分支处理4xx错误,返回相应的错误提示文件。
  出了switch语句之后,接着是一个if判断file_finished的值。如果值为1,说明不需要给客户端返回文件数据。对于1xx,204和 304状态,将Content-Length设置为空值。如果method是HEAD,那么服务器可能需要返回一些数据,这时候要设置对应的 Content-Length。如果file_finished的值为0,那么要设置一下keep_alive的值。在 connection_handle_write_prepare函数的最后,调用http_response_write_header将 headers写入write_queue,等待返回给客户端。如果一切顺利,那么状态机进入CON_STATE_WRITE。
  由于数据可能不会一次写完,尤其是发送大文件的时候。因此,在CON_STATE_WRITE状态中首先判断write_queue时候为空,也就是有没 有数据还没有发送。同时判断连接是否可写。如果有数据且可写,那么调用connection_handle_write发送数据。如果没有数据可写或者连 接不可写,那么会退出switch(con->state)这个语句。同时,由于状态机状态没有发生改变,switch后面的if语句使得服务器退 出了大while循环,进入循环后面的小switch(con->state)语句。这个switch语句在前面已经介绍过。在这里,进入 CON_STATE_WRITE分支,如果有数据可写且连接可写且没有达到流量限制,那么在fdevent中注册这个连接,否则,删除这个连接。
  下面我们进入connection_handle_write函数,看看有数据可写且连接可写的情况。connection_handle_write函 数会首先在switch语句中调用network_write_chunkqueue函数。顾名思义,这个函数就是将write_queue中的数据写回 给客户端的。函数network_write_chunkqueue首先判断当前连接的流量是否超过了限制,如果是,则不发送任何数据,直接将连接加到作 业列表(joblist)中,让其他连接发送数据。如果没有超限,那么首先设置TCP_CORK选项。这个选项可以将多个write调用的数据一起发送, 提高发送效率。有关TCP_CORK的内容读者可自行google之。接下来就是调用srv->network_backend_wirte()函 数进行真正的写数据了。这个函数的真正定义有多个,在network_*.c文件中。服务器在network.c的network_init函数中会根据 当前的运行环境设置不同的值。为了提高服务器的效率,不同的OS会提供一些不同的方法,提高发送文件的速度。通过传统的先read在write的方法,需 要4次数据拷贝(从磁盘到内核缓冲区,从内核缓冲区到用户缓冲区,从用户缓冲区到网络接口的内核缓冲区,最后,从网络接口的内核缓冲区到网络设备缓冲 区。),OS会提供一些特定的方法来减少拷贝的次数,具体读者可以google“直接IO”,有不少介绍这个的文章。为了充分利用这些方法来提高服务器的 性能,lighttpd在不同的OS上都会去使用这些特定的接口,因此就需要多个network_backend_wirte函数的实现。这些实现基本上 大同小异,因此这里只介绍network_write.c中的实现。函数的主体是个大循环,遍历所有的chunk。如果chunk的类型是 MEM_CHUNK,那么这个chunk中的数据是在内存中的,直接调用write或者windows下的send函数发送数据。如果是 FILE_CHUNK类型,说明这个chunk表示的是一个文件,那么如果运行环境有mmap函数,就使用mmap映射文件并发送,否则就read在 write。如果这个chunk发送完了,那么继续发送下一个chunk。如果没有发送完(chunk_finished=0),那么退出循环,接着也就 退出了这个函数。服务器这时返回到network_write_chunkqueue中,下面做一些统计工作,再一次检查该连接的流量是否超限。最后服务 器返回到connection_handle_write中。如果network_write_chunkqueue返回-1,表示服务器出错。状态机进 入CON_STATE_ERROR。如果返回-2,则客户端关闭连接,状态机也进入CON_STATE_ERROR。返回0表示发送完毕,进入下一个状 态。返回1说明数据没有发送完,标记is_wirtable为0。
  从connection_handler_write函数返回后,如果数据没有发送完毕,那么状态机还在
CON_STATE_WRITE状态,接着连接被加到fdevent系统中,等待下一次数据发送。重复上述过程知道发送完毕或出错。
  如果数据发送完毕,状态机进入CON_STATE_RESPONSE_END状态。在这个状态中,服务器首先调用 plugins_call_handle_request_done通知所有插件连接处理完毕。然后判断是否保持连接,如果保持,将状态机设置为 CON_STATE_REQUEST_START。如果不保持,那么先调用plugins_call_handle_connection_close通 知所有插件连接关闭。然后关闭连接。最后,重置con,清除前一次请求的数据。
  至此,请求处理结束。总的来说,返回response的过程还算直接,没有多少难懂的地方。比较不好懂的地方都是关于http协议中一些情况的细节处理,读者可以参照rfc理解。
下面一片文章将会分析一些错误处理过程。

本文章由 http://www.wifidog.pro/2015/04/10/wifidog%E8%AE%A4%E8%AF%81lighttpd-1.html 整理编辑,转载请注明出处