HTTP分為URI，HEADER，Body三個部分。每個部分都可以包含請求信息，那么每個部分是否都有請求大小限制呢？剛開始以為這個問題很容易找到答案，后來發(fā)現(xiàn)這也是個挺復(fù)雜的問題。
URI
首先是URI，我們知道，在GET請求中，請求參數(shù)是放在URL進(jìn)行傳遞的，所以，HTTP GET的請求最關(guān)心的一個問題：能有多長？我能放多少參數(shù)？URI
從HTTP 1.1協(xié)議中開始找：（RFC 2616）
The HTTP protocol does not place any a priori limit on the length of a URI
所以明確一點的是HTTP協(xié)議是沒有顯式限制URI的長度的。理論上來說你在URI中傳遞多少參數(shù)都是可以的。

但是現(xiàn)實往往無法永遠(yuǎn)照進(jìn)陽光：
1 瀏覽器限制
所有主流瀏覽器都會對URI的長度進(jìn)行限制。如果你在瀏覽器中輸入過長的URI，那么瀏覽器會自動進(jìn)行截斷。各個瀏覽器對URI長度的限制各不相同，甚至不同版本也不一樣。大約一個概念，2000字符以內(nèi)的URI都能符合所有主流瀏覽器的要求。
2 服務(wù)端限制
即使客戶端同意發(fā)送無限長度的URI，但是服務(wù)器一方一般都是有長度限制的。一般服務(wù)是沒有專門針對URI的參數(shù)限制的，但是由于URI是會包含在request header中的，所以對header的大小限制是會對URI起作用的，比如nginx的（large_client_header_buffers）這個屬性，它默認(rèn)是4k。

題外話
這里的“URI是包含在request header中的” 這句話其實是有問題的。URI在HTTP協(xié)議中是叫做request-Line的，如果具體看協(xié)議，是會發(fā)現(xiàn)request-Line和request-header是兩個不一樣的，就是說request的請求其實該分為request-line, request-header, request-body三個部分的（具體可以看http://www.ietf.org/rfc/rfc2616.txt 第4和5章）。但是好像使用的時候都默認(rèn)將header中理解為包含了request-line（比如這篇文章http://trafficserver.apache.org/docs/v2/sdk/HTTPHeaders.html）。這里估計是概念和使用的時候?qū)е聠栴}，不必深究了，所以我們不妨將request-line理解為包含在header中就好。

不管如何，綜上所述，這里的URI不論是客戶端還是服務(wù)端，基本是被默認(rèn)限制住的。
Header
header中存放的信息非常多，比如request-line，cookie，還有各種key-value的特定header字段和值。有點時候，我們也會往header中添加一些自定義的屬性。header的長度和URI的情況是一樣的。協(xié)議中并沒有顯示限制header的大小。理論上在header中放多少屬性都是可以的。
但是實際上：
1 瀏覽器限制
各個主流瀏覽器限制幾十k～幾百M不等的限制?；旧夏軡M足平時的需求了。但是如果這個長度對你業(yè)務(wù)有很大影響的話，建議還是親自測試下。
2 服務(wù)端限制
比如nginx的large_client_header_buffers就限制了header的長度。你也可以自己設(shè)置。

可能會影響header的參數(shù)還有：
client_header_buffer_size
client_header_timeout
各參數(shù)可以參考：http://wiki.nginx.org/HttpCoreModule
Body
body和URI，header非常不一樣，不一樣的地方原因在于文件上傳。HTTP是支持request中帶文件的，那么文件的二進(jìn)制數(shù)據(jù)不會放在URI或者h(yuǎn)eader里面，它是放在body里面的。那么這個body的大小就一定不能默認(rèn)限制太小，尤其是客戶端。

首先理論上，協(xié)議是沒有對body大小做任何限制的。
其次，瀏覽器也沒有對body做任何大小限制，因為如果瀏覽器做了大小限制就意味著它直接影響了你的服務(wù)功能。
所以對body的限制的任務(wù)就放在了服務(wù)器上了。這里就我最熟悉的nginx+php-fpm來看下有哪些地方可以對body進(jìn)行限制：
1 nginx有一些設(shè)置會對body大小產(chǎn)生影響
client_max_body_size，這個參數(shù)可以限制body的大小，默認(rèn)是1m
client_body_timeout，當(dāng)body太大，或者網(wǎng)絡(luò)太差的時候，這個也有可能會影響請求的成功率的。
2 php.ini也有一些設(shè)置會對上傳的body數(shù)據(jù)產(chǎn)生影響
upload_max_filesize，限制最大上傳文件大小
post_max_size ，限制post的大小
memory_limit，限制內(nèi)存使用大小
max_execution_time，這個是php最大執(zhí)行時間，也有可能影響請求成功率的。
HTTP請求大小有什么影響
首先是安全因素考慮。
試想一下一個網(wǎng)站的服務(wù)器是不限制body大小的，那么它就是可以被黑客利用攻擊的地方了。黑客利用這一點往HTTP POST的body中傳遞非常大（比如幾M）的請求。那么比如像nginx+php-fpm這樣的，就會占用了服務(wù)器一個php進(jìn)程專門處理這個請求，就會導(dǎo)致你對外無法提供其他的服務(wù)了，你的服務(wù)就癱瘓了，這就是DDOS攻擊。
其次是文件上傳服務(wù)考慮。
文件上傳有兩種情況：
你可能經(jīng)常遇到為什么文件上傳失?。磕敲创蠖嗍巧衔恼f的幾個設(shè)置沒有設(shè)置對。
其次，文件上傳大小是不是設(shè)置越大越好？答案必須是否定的，理由也是安全考慮。滿足需求的大小限制就夠了。
這里就可以理解為什么大都把文件上傳和業(yè)務(wù)接口分開來提供了吧。如果你的文件上傳服務(wù)和業(yè)務(wù)接口是同一個機器的話，那么就說明你的業(yè)務(wù)接口可以允許的body大小一定是很大的。換句話說，在這種情境下，你的業(yè)務(wù)中的所有POST請求都是不安全的??！只要進(jìn)行DDOS攻擊，業(yè)務(wù)就會癱瘓。