1、tcp長(zhǎng)短連接：

短連接：短連接一般只會(huì)在 client/server 間傳遞一次讀寫操作

建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接

長(zhǎng)連接：一次讀寫完成，連接不關(guān)閉、長(zhǎng)時(shí)間操作之后client發(fā)起關(guān)閉請(qǐng)求

建立連接——數(shù)據(jù)傳輸...（保持連接）...數(shù)據(jù)傳輸——關(guān)閉連接

優(yōu)缺點(diǎn)：長(zhǎng)連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費(fèi)，節(jié)約時(shí)間；對(duì)于頻繁請(qǐng)求資源的客戶來(lái)說(shuō)，較適用長(zhǎng)連接。

短連接對(duì)于服務(wù)器來(lái)說(shuō)管理較為簡(jiǎn)單，存在的連接都是有用的連接，不需要額外的控制手段；但如果客戶請(qǐng)求頻繁，將在TCP的建立和關(guān)閉操作上浪費(fèi)時(shí)間和帶寬

注意點(diǎn)：server端需要關(guān)閉一些長(zhǎng)時(shí)間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損

如果條件再允許就可以以客戶端機(jī)器為顆粒度，限制每個(gè)客戶端的最大長(zhǎng)連接數(shù)

應(yīng)用場(chǎng)景：

長(zhǎng)連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況。

每個(gè)TCP連接都需要三次握手，這需要時(shí)間，如果每個(gè)操作都是先連接，

再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開，

再次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。

例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接，如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，

而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。

而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L(zhǎng)連接對(duì)于服務(wù)端來(lái)說(shuō)會(huì)耗費(fèi)一定的資源，

而像WEB網(wǎng)站這么頻繁的成千上萬(wàn)甚至上億客戶端的連接用短連接會(huì)更省一些資源，

如果用長(zhǎng)連接，而且同時(shí)有成千上萬(wàn)的用戶，如果每個(gè)用戶都占用一個(gè)連接的話，

那可想而知吧。所以并發(fā)量大，但每個(gè)用戶無(wú)需頻繁操作情況下需用短連好。

2、單進(jìn)程服務(wù)器-epoll：

IO 多路復(fù)用：就是我們說(shuō)的select，poll，epoll，有些地方也稱這種IO方式為event driven IO。

3、小注意點(diǎn)：

from gevent import monkey將所有阻塞轉(zhuǎn)為gevent方法

HTTP/1.1長(zhǎng)連接1.0短鏈接

decode("utf-8")解碼、encode("utf-8")編碼

Apache穩(wěn)定、nginx效率高