1.MPM框架負責(zé)多進程或多線程的并發(fā)處理，它偵聽指定的套接字，一旦客戶端請求到來，它將立即接受該請求，并創(chuàng)建相應(yīng)的連接。而一旦連接建立完畢，核心將從該連接上讀取請求的數(shù)據(jù)。

??

整個HTTP連接處理的過程可以分為下面幾大部分:

? ?(1) 接收連接

? ?(2) 創(chuàng)建連接

? ?(3) 連接預(yù)處理

? ?(4) 請求處理

? ?(5) 清除連接和關(guān)閉連接

2.等待連接的過程就是調(diào)用套接字函數(shù)listen的過程。Apache中使用封裝后的APR函數(shù)ap_setup_listeners進行偵聽。對于MPM來說，該函數(shù)在掛鉤open_logs被調(diào)用的時候觸發(fā)。

3.Apache核心將創(chuàng)建一個conn_rec結(jié)構(gòu)，連接的創(chuàng)建通過create_connection掛鉤完成。

struct conn_rec {apr_pool_t *pool;server_rec *base_server;void *vhost_lookup_data;apr_sockaddr_t *local_addr;apr_sockaddr_t *remote_addr;char *remote_ip;char *remote_host;char *remote_logname;char *local_ip;char *local_host;ap_conn_keepalive_e keepalive;signed int double_reverse:2;int keepalives;unsigned aborted:1;long id;struct ap_conf_vector_t *conn_config;apr_table_t *notes;struct ap_filter_t *input_filters;struct ap_filter_t *output_filters;void *sbh;struct apr_bucket_alloc_t *bucket_alloc;conn_state_t *cs;int data_in_input_filters;int clogging_input_filters; };

4.套接字綁定和偵聽流程:

? ?

? ?open_listeners內(nèi)部的主要工作包括三部分:

? ? ?(1) 對于每一個套接字，調(diào)用make_sock函數(shù)，將其與給定的IP地址/端口綁定在一起，同時在指定的端口上進行偵聽。

? ? ?(2) 如果本次是重新啟動，那么啟動前的偵聽套接字都保存在old_listeners中，這些偵聽套接字都不再需要了，此時必須將它們逐一關(guān)閉;

? ? ?(3) 注冊偵聽套接字內(nèi)存池清理函數(shù)。

?

? ? ?conn_rec中的notes字段的作用:它通常類似于一個中介傳輸者，在不同的模塊和不同的函數(shù)之間傳遞一個信息。通常情況下某個函數(shù)將須要傳遞其余函數(shù)的信息設(shè)置在notes中，其余的函數(shù)則相應(yīng)從中獲取，類似于一個傳送帶，如下圖:

? ? ?

? ? ?一旦建成conn_rec結(jié)構(gòu)，MPM模塊將會調(diào)用ap_process_connection()對該連接進行進一步處理。ap_process_connection()是整個Apache的核心部分，至此，Apache將脫離MPM模塊的控制，進入請求-響應(yīng)循環(huán)。

? ??

? (1) 使用ap_update_vhost_given_ip()函數(shù)確定該連接IP地址所對應(yīng)的所有虛擬主機;

? (2) 調(diào)用pre_connection掛鉤。

? (3) 調(diào)用process_connection掛鉤處理該連接。

5.pre_connection階段的一項重要任務(wù)就是在過濾器堆棧中插入新的連接過濾器。

? ? 目前Apache中實現(xiàn)該掛鉤的模塊包括: core、ssl模塊、nw_ssl、logio模塊、dumpio模塊

? ? 總而言之，在處理連接之前需要做的任何與連接相關(guān)的準備工作都可以放到pre_connection中去處理。

6.HTTP連接處理的主要內(nèi)容包括兩方面:讀取連接上的請求數(shù)據(jù)及處理這些請求數(shù)據(jù)。Apache中通過ap_read_request函數(shù)完成一次請求讀取，而請求的處理則由函數(shù)ap_process_request完成。

7.一個HTTP請求連接通常會對應(yīng)多個request_rec結(jié)構(gòu)

? ??

8.請求讀取實現(xiàn)

? ?

? ?請求讀取流程:

? ?

9.HTTP/1.1 協(xié)議規(guī)定(RFC2616 14.23節(jié)),瀏覽器必須發(fā)送host請求頭，因此，當發(fā)現(xiàn)協(xié)議為1.1.版本時，同時卻沒有告知完整的URL或沒有在請求行中請求host域，這種情況是不允許的，此時將直接發(fā)送錯誤響應(yīng)，返回錯誤碼為400.

10.如果服務(wù)器收到的頭信息存在Expect域，同時值為100-continue的請求，這是指客戶端詢問是否可以在后續(xù)的請求中發(fā)送附件。在這種情況下，服務(wù)器用100(SC_CONTINUE)允許客戶端繼續(xù)或用417(Expectation Failed)告訴客戶端不同意接受附件。這個狀態(tài)碼是HTTP 1.1中新加入的。如果存在非空的Expect頭域，同時值為"100-continue",則將請求的expecting_100設(shè)置為1，這樣返回給客戶端，允許繼續(xù)發(fā)送附件。如果請求頭域的值無法識別，那么進行出錯處理，發(fā)送響應(yīng)，記錄日志。

11.請求頭的讀取使用ap_get_mime_headers_core實現(xiàn)。

12.實際報文的逐行讀取是通過函數(shù)ap_rgetline完成的，該函數(shù)的內(nèi)部調(diào)用了ap_rgetline_core函數(shù)。ap_rgetline_core函數(shù)完成實際的IO讀取工作。

?

?

總結(jié)

以上是生活随笔為你收集整理的学习《apache源代码全景分析》之网络连接部分摘录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。