您好,登錄后才能下訂單哦!
怎么在Nginx中實現反向代理并支持長連接?很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
前言
Nginx upstream與后端的連接默認為短連接,通過HTTP/1.0向后端發起連接,并把請求的"Connection" header設為"close"。Nginx與前端的連接默認為長連接,一個用戶跟Nginx建立連接之后,通過這個長連接發送多個請求。如果Nginx只是作為reverse proxy的話,可能一個用戶連接就需要多個向后端的短連接。如果后端的服務器(源站或是緩存服務器)處理并發連接能力不強的話,就可能導致瓶頸的出現。
Nginx目前的upstream連接建立和獲取的機制如下圖。Nginx會在一開始創建connection pool(進程間不共享,可以避免鎖),提供給所有向前/后的連接。
如果要實現upstream長連接,則每個進程需要另外一個connection pool,里面都是長連接。一旦與后端服務器建立連接,則在當前請求連接結束之后不會立即關閉連接,而是把用完的連接保存在一個keepalive connection pool里面,以后每次需要建立向后連接的時候,只需要從這個連接池里面找,如果找到合適的連接的話,就可以直接來用這個連接,不需要重新創建socket或者發起connect()。這樣既省下建立連接時三次握手的時間消耗,又可以避免TCP連接的slow start。如果在keepalive連接池找不到合適的連接,那就按照原來的步驟重新建立連接。假設連接查找時間可以忽略不計,那么這種方法肯定是有益而無害的(當然,需要少量額外的內存)。
具體如何來設計這個keepalive connection pool,不同人有不同的選擇。比如Nginx目前的第三方模塊upstream keepalive(作者Maxim Dounin)使用了一個queue來做。因為upstream的服務器很可能是多個,所以可能當保持的連接數多的時候,查找的時間可能會較長。可以給每個upstream服務器都分配一個pool(queue),縮短查找時間。但是總體來說內存操作很快,影響不會很大。upstream keepalive模塊目前只支持memcached,但是可以重用其代碼來達到對http upstream的長連接。由于Nginx作者之前沒有考慮upstream的長連接,所以在設計上要把http upstream keepalive模塊化可能比較難,只能通過手動修改代碼來做到。
一個完整的讓upstream支持長連接的配置示例如下:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 |
|
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。