setsockopt()使用方法（參数具体说明）
int setsockopt(
SOCKET s,
int level,
int optname,
const char* optval,
int optlen
);
s(套接字): 指向一個(gè)打開(kāi)的套接口描寫敘述字
level:(級(jí)別)： 指定選項(xiàng)代碼的類型。
SOL_SOCKET: 基本套接口
IPPROTO_IP: IPv4套接口
IPPROTO_IPV6: IPv6套接口
IPPROTO_TCP: TCP套接口
optname(選項(xiàng)名)： 選項(xiàng)名稱
optval(選項(xiàng)值): 是一個(gè)指向變量的指針 類型：整形，套接口結(jié)構(gòu)， 其它結(jié)構(gòu)類型:linger{}, timeval{ }
optlen(選項(xiàng)長(zhǎng)度) ：optval 的大小
返回值：標(biāo)志打開(kāi)或關(guān)閉某個(gè)特征的二進(jìn)制選項(xiàng)
[/code:1:59df4ce128]
========================================================================
SOL_SOCKET
------------------------------------------------------------------------
SO_BROADCAST 同意發(fā)送廣播數(shù)據(jù) int
適用於 UDP socket。其意義是同意 UDP socket 「廣播」（broadcast）訊息到網(wǎng)路上。
SO_DEBUG 同意調(diào)試 int
SO_DONTROUTE 不查找路由 int
SO_ERROR 獲得套接字錯(cuò)誤 int
SO_KEEPALIVE 保持連接 int
檢 測(cè)對(duì)方主機(jī)是否崩潰，避免（server）永遠(yuǎn)堵塞于TCP連接的輸入。 設(shè)置該選項(xiàng)后，假設(shè)2小時(shí)內(nèi)在此套接口的任一方向都沒(méi)有數(shù)據(jù)交換，TCP就自己主動(dòng)給對(duì)方 發(fā)一個(gè)保持存活探測(cè)分節(jié)(keepalive probe)。這是一個(gè)對(duì)方必須響應(yīng)的TCP分節(jié).它會(huì)導(dǎo)致下面三種情況： 對(duì)方接收一切正常：以期望的 ACK響應(yīng)。2小時(shí)后，TCP將發(fā)出還有一個(gè)探測(cè)分節(jié)。 對(duì)方已崩潰且已又一次啟動(dòng)：以RST響應(yīng)。套接口的待處理錯(cuò)誤被置為ECONNRESET，套接 口本身則被關(guān)閉。 對(duì)方無(wú)不論什么響應(yīng)：源自berkeley的TCP發(fā)送另外8個(gè)探測(cè)分節(jié)，相隔75秒一個(gè)，試圖得到 一個(gè)響應(yīng)。在發(fā)出第一個(gè)探測(cè)分節(jié)11分鐘15秒后若仍無(wú)響應(yīng)就放棄。套接口的待處理錯(cuò) 誤被置為ETIMEOUT，套接口本身則被關(guān)閉。如ICMP錯(cuò)誤是“host unreachable (主機(jī)不 可達(dá))”，說(shuō)明對(duì)方主機(jī)并沒(méi)有崩潰，可是不可達(dá)，這樣的情況下待處理錯(cuò)誤被置為 EHOSTUNREACH。
SO_DONTLINGER 若為真，則SO_LINGER選項(xiàng)被禁止。
SO_LINGER 延遲關(guān)閉連接 struct linger
上面這兩個(gè)選項(xiàng)影響close行為
選項(xiàng) 間隔 關(guān)閉方式 等待關(guān)閉與否
SO_DONTLINGER 不關(guān)心 優(yōu)雅 否
SO_LINGER 零 強(qiáng)制 否
SO_LINGER 非零 優(yōu)雅 是
若 設(shè)置了SO_LINGER（亦即linger結(jié)構(gòu)中的l_onoff域設(shè)為非零，參見(jiàn)2.4，4.1.7和4.1.21各節(jié)），并設(shè)置了零超時(shí)間隔，則 closesocket()不被堵塞馬上運(yùn)行，不論是否有排隊(duì)數(shù)據(jù)未發(fā)送或未被確認(rèn)。這樣的關(guān)閉方式稱為“強(qiáng)制”或“失效”關(guān)閉，由于套接口的虛電路馬上被 復(fù)位，且丟失了未發(fā)送的數(shù)據(jù)。在遠(yuǎn)端的recv()調(diào)用將以WSAECONNRESET出錯(cuò)。
若設(shè)置了SO_LINGER并確定了非零的超時(shí)間 隔，則closesocket()調(diào)用堵塞進(jìn)程，直到所剩數(shù)據(jù)發(fā)送完成或超時(shí)。這樣的關(guān)閉稱為“優(yōu)雅的”關(guān)閉。請(qǐng)注意假設(shè)套接口置為非堵塞且 SO_LINGER設(shè)為非零超時(shí)，則closesocket()調(diào)用將以WSAEWOULDBLOCK錯(cuò)誤返回。
若在一個(gè)流類套接口上設(shè)置了 SO_DONTLINGER（也就是說(shuō)將linger結(jié)構(gòu)的l_onoff域設(shè)為零；參見(jiàn)2.4，4.1.7，4.1.21節(jié)），則 closesocket()調(diào)用馬上返回。可是，假設(shè)可能，排隊(duì)的數(shù)據(jù)將在套接口關(guān)閉前發(fā)送。請(qǐng)注意，在這樣的情況下WINDOWS套接口實(shí)現(xiàn)將在一段不確 定的時(shí)間內(nèi)保留套接口以及其它資源，這對(duì)于想用所以套接口的應(yīng)用程序來(lái)說(shuō)有一定影響。
SO_OOBINLINE 帶外數(shù)據(jù)放入正常數(shù)據(jù)流,在普通數(shù)據(jù)流中接收帶外數(shù)據(jù) int
SO_RCVBUF 接收緩沖區(qū)大小 int
設(shè)置接收緩沖區(qū)的保留大小
與 SO_MAX_MSG_SIZE 或TCP滑動(dòng)窗體無(wú)關(guān)，假設(shè)一般發(fā)送的包非常大非常頻繁，那么使用這個(gè)選項(xiàng)
SO_SNDBUF 發(fā)送緩沖區(qū)大小 int
設(shè)置發(fā)送緩沖區(qū)的保留大小
與 SO_MAX_MSG_SIZE 或TCP滑動(dòng)窗體無(wú)關(guān)，假設(shè)一般發(fā)送的包非常大非常頻繁，那么使用這個(gè)選項(xiàng)
每 個(gè)套接口都有一個(gè)發(fā)送緩沖區(qū)和一個(gè)接收緩沖區(qū)。 接收緩沖區(qū)被TCP和UDP用來(lái)將接收到的數(shù)據(jù)一直保存到由應(yīng)用進(jìn)程來(lái)讀。 TCP：TCP通告還有一端的窗體大小。 TCP套接口接收緩沖區(qū)不可能溢出，由于對(duì)方不同意發(fā)出超過(guò)所通告窗體大小的數(shù)據(jù)。 這就是TCP的流量控制，假設(shè)對(duì)方無(wú)視窗體大小而發(fā)出了超過(guò)宙口大小的數(shù)據(jù)，則接 收方TCP將丟棄它。 UDP：當(dāng)接收到的數(shù)據(jù)報(bào)裝不進(jìn)套接口接收緩沖區(qū)時(shí)，此數(shù)據(jù)報(bào)就被丟棄。UDP是沒(méi)有 流量控制的；快的發(fā)送者能夠非常easy地就淹沒(méi)慢的接收者，導(dǎo)致接收方的UDP丟棄數(shù)據(jù)報(bào)。
SO_RCVLOWAT 接收緩沖區(qū)下限 int
SO_SNDLOWAT 發(fā)送緩沖區(qū)下限 int
每 個(gè)套接口都有一個(gè)接收低潮限度和一個(gè)發(fā)送低潮限度。它們是函數(shù)selectt使用的， 接收低潮限度是讓select返回“可讀”而在套接口接收緩沖區(qū)中必須有的數(shù)據(jù)總量。 ——對(duì)于一個(gè)TCP或UDP套接口，此值缺省為1。發(fā)送低潮限度是讓select返回“可寫” 而在套接口發(fā)送緩沖區(qū)中必須有的可用空間。對(duì)于TCP套接口，此值常缺省為2048。 對(duì)于UDP使用低潮限度， 因?yàn)槠浒l(fā)送緩沖區(qū)中可用空間的字節(jié)數(shù)是從不變化的，僅僅要 UDP套接口發(fā)送緩沖區(qū)大小大于套接口的低潮限度，這種UDP套接口就總是可寫的。 UDP沒(méi)有發(fā)送緩沖區(qū)，僅僅有發(fā)送緩沖區(qū)的大小。
SO_RCVTIMEO 接收超時(shí) struct timeval
SO_SNDTIMEO 發(fā)送超時(shí) struct timeval
SO_REUSERADDR 同意重用本地地址和port int
充許綁定已被使用的地址（或port號(hào)），能夠參考bind的man
SO_EXCLUSIVEADDRUSE
獨(dú)占模式使用port,就是不充許和其他程序使用SO_REUSEADDR共享的使用某一port。
在確定多重綁定使用誰(shuí)的時(shí)候，依據(jù)一條原則是誰(shuí)的指定最明白則將包遞交給誰(shuí)，并且沒(méi)有權(quán)限之分，也就是說(shuō)低級(jí)權(quán)限的用戶是能夠重綁定在高級(jí)權(quán)限如服務(wù)啟動(dòng)的port上的,這是很重大的一個(gè)安全隱患,
假設(shè)不想讓自己程序被監(jiān)聽(tīng)，那么使用這個(gè)選項(xiàng)
SO_TYPE 獲得套接字類型 int
SO_BSDCOMPAT 與BSD系統(tǒng)兼容 int
==========================================================================
IPPROTO_IP
--------------------------------------------------------------------------
IP_HDRINCL 在數(shù)據(jù)包中包括IP首部 int
這個(gè)選項(xiàng)經(jīng)常使用于黑客技術(shù)中，隱藏自己的IP地址
IP_OPTINOS IP首部選項(xiàng) int
IP_TOS 服務(wù)類型
IP_TTL 生存時(shí)間 int
下面IPV4選項(xiàng)用于組播
IPv4 選項(xiàng) 數(shù)據(jù)類型 描 述
IP_ADD_MEMBERSHIP struct ip_mreq 添�到組播組中
IP_ROP_MEMBERSHIP struct ip_mreq 從組播組中退出
IP_MULTICAST_IF struct ip_mreq 指定提交組播報(bào)文的接口
IP_MULTICAST_TTL u_char 指定提交組播報(bào)文的TTL
IP_MULTICAST_LOOP u_char 使組播報(bào)文環(huán)路有效或無(wú)效
在頭文件里定義了ip_mreq結(jié)構(gòu)：
[code:1:63724de67f]
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_interface; /* local IP address of interface */
};
[/code:1:63724de67f]
若進(jìn)程要添�到一個(gè)組播組中，用soket的setsockopt()函數(shù)發(fā)送該選項(xiàng)。該選項(xiàng)類型是ip_mreq結(jié)構(gòu)，它的第一個(gè)字段imr_multiaddr指定了組播組的地址，第二個(gè)字段imr_interface指定了接口的IPv4地址。
IP_DROP_MEMBERSHIP
該選項(xiàng)用來(lái)從某個(gè)組播組中退出。數(shù)據(jù)結(jié)構(gòu)ip_mreq的用法與上面同樣。
IP_MULTICAST_IF
該選項(xiàng)能夠改動(dòng)網(wǎng)絡(luò)接口，在結(jié)構(gòu)ip_mreq中定義新的接口。
IP_MULTICAST_TTL
設(shè)置組播報(bào)文的數(shù)據(jù)包的TTL（生存時(shí)間）。默認(rèn)值是1，表示數(shù)據(jù)包僅僅能在本地的子網(wǎng)中傳送。
IP_MULTICAST_LOOP
組播組中的成員自己也會(huì)收到它向本組發(fā)送的報(bào)文。這個(gè)選項(xiàng)用于選擇是否激活這樣的狀態(tài)。
無(wú)雙 回復(fù)于：2003-05-08 21:21:52
IPPRO_TCP
--------------------------------------------------------------------------
TCP_MAXSEG TCP最大數(shù)據(jù)段的大小 int
獲 取或設(shè)置TCP連接的最大分節(jié)大小(MSS)。返回值是我們的TCP發(fā)送給還有一端的最大 數(shù)據(jù)量，它經(jīng)常就是由還有一端用SYN分節(jié)通告的MSS，除非我們的TCP選擇使用一個(gè)比 對(duì)方通告的MSS小些的值。假設(shè)此值在套接口連接之前取得，則返回值為未從另·—端 收到Mss選項(xiàng)的情況下所用的缺省值。小于此返回值的信可能真正用在連接上，由于譬 如說(shuō)使用時(shí)間戳選項(xiàng)的話，它在每一個(gè)分節(jié)上占用12字節(jié)的TCP選項(xiàng)容量。我們的TcP將 發(fā)送的每一個(gè)分節(jié)的最大數(shù)據(jù)量也可在連接存活期內(nèi)改變，但前提是TCP要支持路徑MTU 發(fā)現(xiàn)功能。假設(shè)到對(duì)方的路徑改變了，此值可上下調(diào)整。
TCP_NODELAY 不使用Nagle算法 int
指定TCP開(kāi)始發(fā)送保持存活探測(cè)分節(jié)前以秒為單位的連接空暇時(shí)間。缺省值至少必須為7200秒，即2小時(shí)。此選項(xiàng)僅在SO_KEPALIVEE套接口選項(xiàng)打開(kāi)時(shí)才有效。
TCP_NODELAY 和 TCP_CORK，
這 兩個(gè)選項(xiàng)都對(duì)網(wǎng)絡(luò)連接的行為具有關(guān)鍵的數(shù)據(jù)。很多UNIX系統(tǒng)都實(shí)現(xiàn)了TCP_NODELAY選項(xiàng)，可是，TCP_CORK則是Linux系統(tǒng)所獨(dú)有的而 且相對(duì)較新；它首先在內(nèi)核版本號(hào)2.4上得以實(shí)現(xiàn)。此外，其它UNIX系統(tǒng)版本號(hào)也有功能相似的選項(xiàng)，值得注意的是，在某種由BSD派生的系統(tǒng)上的 TCP_NOPUSH選項(xiàng)事實(shí)上就是TCP_CORK的一部分詳細(xì)實(shí)現(xiàn)。
TCP_NODELAY和TCP_CORK基本上控制了包的 “Nagle化”，Nagle化在這里的含義是採(cǎi)用Nagle算法把較小的包組裝為更大的幀。John Nagle是Nagle算法的發(fā)明人，后者就是用他的名字來(lái)命名的，他在1984年首次用這樣的方法來(lái)嘗試解決福特汽車公司的網(wǎng)絡(luò)擁塞問(wèn)題（欲了解詳情請(qǐng)參 看IETF RFC 896）。他解決的問(wèn)題就是所謂的silly window syndrome ，中文稱“愚蠢窗體癥候群”，詳細(xì)含義是，由于普遍終端應(yīng)用程序每產(chǎn)生一次擊鍵操作就會(huì)發(fā)送一個(gè)包，而典型情況下一個(gè)包會(huì)擁有一個(gè)字節(jié)的數(shù)據(jù)載荷以及40 個(gè)字節(jié)長(zhǎng)的包頭，于是產(chǎn)生4000%的過(guò)載，非常輕易地就能令網(wǎng)絡(luò)發(fā)生擁塞,。 Nagle化后來(lái)成了一種標(biāo)準(zhǔn)并且馬上在因特網(wǎng)上得以實(shí)現(xiàn)。它如今已經(jīng)成為缺省配置了，但在我們看來(lái)，有些場(chǎng)合下把這一選項(xiàng)關(guān)掉也是合乎須要的。
現(xiàn) 在讓我們假設(shè)某個(gè)應(yīng)用程序發(fā)出了一個(gè)請(qǐng)求，希望發(fā)送小塊數(shù)據(jù)。我們能夠選擇馬上發(fā)送數(shù)據(jù)或者等待產(chǎn)生很多其它的數(shù)據(jù)然后再一次發(fā)送兩種策略。假設(shè)我們馬上發(fā)送 數(shù)據(jù)，那么交互性的以及客戶/server型的應(yīng)用程序?qū)O大地受益。比如，當(dāng)我們正在發(fā)送一個(gè)較短的請(qǐng)求并且等候較大的響應(yīng)時(shí)，相關(guān)過(guò)載與傳輸?shù)臄?shù)據(jù)總量相比 就會(huì)比較低，并且，假設(shè)請(qǐng)求馬上發(fā)出那么響應(yīng)時(shí)間也會(huì)快一些。以上操作能夠通過(guò)設(shè)置套接字的TCP_NODELAY選項(xiàng)來(lái)完畢，這樣就禁用了Nagle算 法。
第二種情況則須要我們等到數(shù)據(jù)量達(dá)到最大時(shí)才通過(guò)網(wǎng)絡(luò)一次發(fā)送所有數(shù)據(jù)，這樣的傳輸數(shù)據(jù)方式故意于大量數(shù)據(jù)的通信性能，典型的應(yīng)用就是文件服 務(wù)器。應(yīng)用 Nagle算法在這樣的情況下就會(huì)產(chǎn)生問(wèn)題。可是，假設(shè)你正在發(fā)送大量數(shù)據(jù)，你能夠設(shè)置TCP_CORK選項(xiàng)禁用Nagle化，其方式正好同 TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。以下就讓我們細(xì)致分析下其工作原理。
假設(shè)應(yīng)用程序 使用sendfile()函數(shù)來(lái)轉(zhuǎn)移大量數(shù)據(jù)。應(yīng)用協(xié)議通常要求發(fā)送某些信息來(lái)預(yù)先解釋數(shù)據(jù)，這些信息事實(shí)上就是報(bào)頭內(nèi)容。典型情況下報(bào)頭非常小，并且套接字 上設(shè)置了TCP_NODELAY。有報(bào)頭的包將被馬上傳輸，在某些情況下（取決于內(nèi)部的包計(jì)數(shù)器），由于這個(gè)包成功地被對(duì)方收到后須要請(qǐng)求對(duì)方確認(rèn)。這 樣，大量數(shù)據(jù)的傳輸就會(huì)被推遲并且產(chǎn)生了不必要的網(wǎng)絡(luò)流量交換。
可是，假設(shè)我們?cè)谔捉幼稚显O(shè)置了TCP_CORK（能夠比喻為在管道上插入 “塞子”）選項(xiàng)，具有報(bào)頭的包就會(huì)填補(bǔ)大量的數(shù)據(jù)，所有的數(shù)據(jù)都依據(jù)大小自己主動(dòng)地通過(guò)包傳輸出去。當(dāng)傳輸數(shù)據(jù)完畢時(shí)，最好取消TCP_CORK 選項(xiàng)設(shè)置給連接“拔去塞子”以便任一部分的幀都能發(fā)送出去。這同“塞住”網(wǎng)絡(luò)連接同等重要。
總而言之，假設(shè)你肯定能一起發(fā)送多個(gè)數(shù)據(jù)集合（比如HTTP響應(yīng)的頭和正文），那么我們建議你設(shè)置TCP_CORK選項(xiàng)，這樣在這些數(shù)據(jù)之間不存在延遲。能極大地故意于WWW、FTP以及文件server的性能，同一時(shí)候也簡(jiǎn)化了你的工作。演示樣例代碼例如以下：
intfd, on = 1;
…
/* 此處是創(chuàng)建套接字等操作，出于篇幅的考慮省略*/
…
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* cork */
write (fd, …);
fprintf (fd, …);
sendfile (fd, …);
write (fd, …);
sendfile (fd, …);
…
on = 0;
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* 拔去塞子 */
不幸的是，很多經(jīng)常使用的程序并沒(méi)有考慮到以上問(wèn)題。比如，Eric Allman編寫的sendmail就沒(méi)有對(duì)其套接字設(shè)置不論什么選項(xiàng)。
Apache HTTPD 是因特網(wǎng)上最流行的Webserver，它的所有套接字就都設(shè)置了TCP_NODELAY選項(xiàng)，并且其性能也深受大多數(shù)用戶的愜意。這是為什么呢？答案就在于實(shí) 現(xiàn)的區(qū)別之上。由BSD衍生的TCP/IP協(xié)議棧（值得注意的是FreeBSD）在這樣的狀況下的操作就不同。當(dāng)在TCP_NODELAY 模式下提交大量小數(shù)據(jù)塊傳輸時(shí)，大量信息將依照一次write()函數(shù)調(diào)用發(fā)送一塊數(shù)據(jù)的方式發(fā)送出去。然而，由于負(fù)責(zé)請(qǐng)求交付確認(rèn)的記數(shù)器是面向字節(jié)而 非面向包（在 Linux上）的，所以引入延遲的概率就減少了非常多。結(jié)果只和所有數(shù)據(jù)的大小有關(guān)系。而 Linux 在第一包到達(dá)之后就要求確認(rèn)，FreeBSD則在進(jìn)行如此操作之前會(huì)等待好幾百個(gè)包。
在Linux系統(tǒng)上，TCP_NODELAY的效果同習(xí)慣于BSD TCP/IP協(xié)議棧的開(kāi)發(fā)人員所期望的效果有非常大不同，并且在Linux上的Apache性能表現(xiàn)也會(huì)更差些。其它在Linux上頻繁採(cǎi)用TCP_NODELAY的應(yīng)用程序也有相同的問(wèn)題。
TCP_DEFER_ACCEPT
我 們首先考慮的第1個(gè)選項(xiàng)是TCP_DEFER_ACCEPT（這是Linux系統(tǒng)上的叫法，其它一些操作系統(tǒng)上也有相同的選項(xiàng)但使用不同的名字）。為了理 解TCP_DEFER_ACCEPT選項(xiàng)的詳細(xì)思想，我們有必要大致闡述一下典型的HTTP客戶/server交互過(guò)程。請(qǐng)回憶下TCP是怎樣與數(shù)據(jù)傳輸?shù)哪繕?biāo) 建立連接的。在網(wǎng)絡(luò)上，在分離的單元之間傳輸?shù)男畔⒎Q為IP包（或IP 數(shù)據(jù)報(bào)）。一個(gè)包總有一個(gè)攜帶服務(wù)信息的包頭，包頭用于內(nèi)部協(xié)議的處理，并且它也能夠攜帶數(shù)據(jù)負(fù)載。服務(wù)信息的典型樣例就是一套所謂的標(biāo)志，它把包標(biāo)記代 表TCP/IP協(xié)議棧內(nèi)的特殊含義，比如收到包的成功確認(rèn)等等。通常，在經(jīng)過(guò)“標(biāo)記”的包里攜帶負(fù)載是全然可能的，但有時(shí)，內(nèi)部邏輯迫使TCP/IP協(xié)議 棧發(fā)出僅僅有包頭的IP包。這些包常常會(huì)引發(fā)討厭的網(wǎng)絡(luò)延遲并且還添加�了系統(tǒng)的負(fù)載，結(jié)果導(dǎo)致網(wǎng)絡(luò)性能在總體上減少。
如今server創(chuàng)建了一個(gè)套接字同 時(shí)等待連接。TCP/IP式的連接過(guò)程就是所謂“3次握手”。首先，客戶程序發(fā)送一個(gè)設(shè)置SYN標(biāo)志并且不帶數(shù)據(jù)負(fù)載的TCP包（一個(gè)SYN包）。server 則以發(fā)出帶SYN/ACK標(biāo)志的數(shù)據(jù)包（一個(gè)SYN/ACK包）作為剛才收到包的確認(rèn)響應(yīng)。客戶隨后發(fā)送一個(gè)ACK包確認(rèn)收到了第2個(gè)包從而結(jié)束連接過(guò) 程。在收到客戶發(fā)來(lái)的這個(gè)SYN/ACK包之后，server會(huì)喚醒一個(gè)接收進(jìn)程等待數(shù)據(jù)到達(dá)。當(dāng)3次握手完畢后，客戶程序即開(kāi)始把“實(shí)用的”的數(shù)據(jù)發(fā)送給服務(wù) 器。通常，一個(gè)HTTP請(qǐng)求的量是非常小的并且全然能夠裝到一個(gè)包里。可是，在以上的情況下，至少有4個(gè)包將用來(lái)進(jìn)行雙向傳輸，這樣就添加�了可觀的延遲時(shí) 間。此外，你還得注意到，在“實(shí)用的”數(shù)據(jù)被發(fā)送之前，接收方已經(jīng)開(kāi)始在等待信息了。
為了減輕這些問(wèn)題所帶來(lái)的影響，Linux（以及其它的一些 操作系統(tǒng)）在其TCP實(shí)現(xiàn)中包含了TCP_DEFER_ACCEPT選項(xiàng)。它們?cè)O(shè)置在偵聽(tīng)套接字的server方，該選項(xiàng)命令內(nèi)核不等待最后的ACK包并且在第 1個(gè)真正有數(shù)據(jù)的包到達(dá)才初始化偵聽(tīng)進(jìn)程。在發(fā)送SYN/ACK包之后，server就會(huì)等待客戶程序發(fā)送含數(shù)據(jù)的IP包。如今，僅僅須要在網(wǎng)絡(luò)上傳送3個(gè)包了， 并且還顯著減少了連接建立的延遲，對(duì)HTTP通信而言尤其如此。
這一選項(xiàng)在好些操作系統(tǒng)上都有對(duì)應(yīng)的對(duì)等物。比如，在FreeBSD上，相同的行為能夠用下面代碼實(shí)現(xiàn)：
/* 為明晰起見(jiàn)，此處略去無(wú)關(guān)代碼 */
struct accept_filter_arg af = { "dataready", "" };
setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af));
這 個(gè)特征在FreeBSD上叫做“接受過(guò)濾器”，并且具有多種使用方法。只是，在差點(diǎn)兒全部的情況下其效果與TCP_DEFER_ACCEPT是一樣的：server不 等待最后的ACK包而只等待攜帶數(shù)據(jù)負(fù)載的包。要了解該選項(xiàng)及其對(duì)高性能Webserver的重要意義的很多其它信息請(qǐng)參考Apache文檔上的有關(guān)內(nèi)容。
就HTTP 客戶/server交互而言，有可能須要改變客戶程序的行為。客戶程序?yàn)槭裁匆l(fā)送這樣的“沒(méi)用的”ACK包呢？這是由于，TCP協(xié)議棧無(wú)法知道ACK包的狀態(tài)。 假設(shè)採(cǎi)用FTP而非HTTP，那么客戶程序直到接收了FTPserver提示的數(shù)據(jù)包之后才發(fā)送數(shù)據(jù)。在這樣的情況下，延遲的ACK將導(dǎo)致客戶/server交互出現(xiàn)延 遲。為了確定ACK是否必要，客戶程序必須知道應(yīng)用程序協(xié)議及其當(dāng)前狀態(tài)。這樣，改動(dòng)客戶行為就成為必要了。
對(duì)Linux客戶程序來(lái)說(shuō)，我們還可 以採(cǎi)用還有一個(gè)選項(xiàng)，它也被叫做TCP_DEFER_ACCEPT。我們知道，套接字分成兩種類型，偵聽(tīng)套接字和連接套接字，所以它們也各自具有對(duì)應(yīng)的 TCP選項(xiàng)集合。因此，常常同一時(shí)候採(cǎi)用的這兩類選項(xiàng)卻具有相同的名字也是全然可能的。在連接套接字上設(shè)置該選項(xiàng)以后，客戶在收到一個(gè)SYN/ACK包之后就 不再發(fā)送ACK包，而是等待用戶程序的下一個(gè)發(fā)送數(shù)據(jù)請(qǐng)求；因此，server發(fā)送的包也就對(duì)應(yīng)降低了。
TCP_QUICKACK
阻 止因發(fā)送無(wú)用包而引發(fā)延遲的還有一個(gè)方法是使用TCP_QUICKACK選項(xiàng)。這一選項(xiàng)與 TCP_DEFER_ACCEPT不同，它不但能用作管理連接建立過(guò)程并且在正常傳輸數(shù)據(jù)過(guò)程期間也能夠使用。另外，它能在客戶/server連接的不論什么一方設(shè) 置。假設(shè)知道數(shù)據(jù)不久即將發(fā)送，那么推遲ACK包的發(fā)送就會(huì)派上用場(chǎng)，并且最好在那個(gè)攜帶數(shù)據(jù)的數(shù)據(jù)包上設(shè)置ACK 標(biāo)志以便把網(wǎng)絡(luò)負(fù)載減到最小。當(dāng)發(fā)送方肯定數(shù)據(jù)將被馬上發(fā)送（多個(gè)包）時(shí)，TCP_QUICKACK 選項(xiàng)能夠設(shè)置為0。對(duì)處于“連接”狀態(tài)下的套接字該選項(xiàng)的缺省值是1，首次使用以后內(nèi)核將把該選項(xiàng)馬上復(fù)位為1（這是個(gè)一次性的選項(xiàng)）。
在某些情形下，發(fā)出ACK包則非常實(shí)用。ACK包將確認(rèn)數(shù)據(jù)塊的接收，并且，當(dāng)下一塊被處理時(shí)不至于引入延遲。這樣的傳輸數(shù)據(jù)模式對(duì)交互過(guò)程是相當(dāng)?shù)湫偷?#xff0c;由于此類情況下用戶的輸入時(shí)刻無(wú)法預(yù)測(cè)。在Linux系統(tǒng)上這就是缺省的套接字行為。
在 上述情況下，客戶程序在向server發(fā)送HTTP請(qǐng)求，而預(yù)先就知道請(qǐng)求包非常短所以在連接建立之后就應(yīng)該馬上發(fā)送，這可謂HTTP的典型工作方式。既然沒(méi)有必 要發(fā)送一個(gè)純粹的ACK包，所以設(shè)置TCP_QUICKACK為0以提高性能是全然可能的。在server方，這兩種選項(xiàng)都僅僅能在偵聽(tīng)套接字上設(shè)置一次。全部的 套接字，也就是被接受呼叫間接創(chuàng)建的套接字則會(huì)繼承原有套接字的全部選項(xiàng)。
通過(guò)TCP_CORK、TCP_DEFER_ACCEPT和 TCP_QUICKACK選項(xiàng)的組合，參與每一HTTP交互的數(shù)據(jù)包數(shù)量將被減少到最小的可接受水平（依據(jù)TCP協(xié)議的要求和安全方面的考慮）。結(jié)果不僅 是獲得更快的傳輸數(shù)據(jù)和請(qǐng)求處理速度并且還使客戶/server雙向延遲實(shí)現(xiàn)了最小化。
二、使用樣例說(shuō)明
1.closesocket（一般不會(huì)馬上關(guān)閉而經(jīng)歷TIME_WAIT的過(guò)程）后想繼續(xù)重用該socket：BOOL bReuseaddr=TRUE;
setsockopt(s,SOL_SOCKET ,SO_REUSEADDR,(const char*)&bReuseaddr,sizeof(BOOL));
2. 假設(shè)要已經(jīng)處于連接狀態(tài)的soket在調(diào)用closesocket后強(qiáng)制關(guān)閉，不經(jīng)歷
TIME_WAIT的過(guò)程：
BOOL bDontLinger = FALSE;
setsockopt(s,SOL_SOCKET,SO_DONTLINGER,(const char*)&bDontLinger,sizeof(BOOL));
3.在send(),recv()過(guò)程中有時(shí)因?yàn)榫W(wǎng)絡(luò)狀況等原因，發(fā)收不能預(yù)期進(jìn)行,而設(shè)置收發(fā)時(shí)限：
int nNetTimeout=1000;//1秒
//發(fā)送時(shí)限
setsockopt(socket，SOL_S0CKET,SO_SNDTIMEO，(char *)&nNetTimeout,sizeof(int));
//接收時(shí)限
setsockopt(socket，SOL_S0CKET,SO_RCVTIMEO，(char *)&nNetTimeout,sizeof(int));
4.在send()的時(shí)候，返回的是實(shí)際發(fā)送出去的字節(jié)(同步)或發(fā)送到socket緩沖區(qū)的字節(jié)
(異步);系統(tǒng)默認(rèn)的狀態(tài)發(fā)送和接收一次為8688字節(jié)(約為8.5K)；在實(shí)際的過(guò)程中發(fā)送數(shù)據(jù)
和接收數(shù)據(jù)量比較大，能夠設(shè)置socket緩沖區(qū)，而避免了send(),recv()不斷的循環(huán)收發(fā)：
// 接收緩沖區(qū)
int nRecvBuf=32*1024;//設(shè)置為32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
//發(fā)送緩沖區(qū)
int nSendBuf=32*1024;//設(shè)置為32K
setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int));
5. 假設(shè)在發(fā)送數(shù)據(jù)的時(shí)，希望不經(jīng)歷由系統(tǒng)緩沖區(qū)到socket緩沖區(qū)的拷貝而影響
程序的性能：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_SNDBUF，(char *)&nZero,sizeof(nZero));
6.同上在recv()完畢上述功能(默認(rèn)情況是將socket緩沖區(qū)的內(nèi)容復(fù)制到系統(tǒng)緩沖區(qū))：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_RCVBUF，(char *)&nZero,sizeof(int));
7.一般在發(fā)送UDP數(shù)據(jù)報(bào)的時(shí)候，希望該socket發(fā)送的數(shù)據(jù)具有廣播特性：
BOOL bBroadcast=TRUE;
setsockopt(s,SOL_SOCKET,SO_BROADCAST,(const char*)&bBroadcast,sizeof(BOOL));
8.在client連接server過(guò)程中，假設(shè)處于非堵塞模式下的socket在connect()的過(guò)程中可
以設(shè)置connect()延時(shí),直到accpet()被呼叫(本函數(shù)設(shè)置僅僅有在非堵塞的過(guò)程中有顯著的
作用，在堵塞的函數(shù)調(diào)用中作用不大)
BOOL bConditionalAccept=TRUE;
setsockopt(s,SOL_SOCKET,SO_CONDITIONAL_ACCEPT,(const char*)&bConditionalAccept,sizeof(BOOL));
9.假設(shè)在發(fā)送數(shù)據(jù)的過(guò)程中(send()沒(méi)有完畢，還有數(shù)據(jù)沒(méi)發(fā)送)而調(diào)用了closesocket(),曾經(jīng)我們
一般採(cǎi)取的措施是"從容關(guān)閉"shutdown(s,SD_BOTH),可是數(shù)據(jù)是肯定丟失了，怎樣設(shè)置讓程序滿足詳細(xì)
應(yīng)用的要求(即讓沒(méi)發(fā)完的數(shù)據(jù)發(fā)送出去后在關(guān)閉socket)？
struct linger {
u_short l_onoff;
u_short l_linger;
};
linger m_sLinger;
m_sLinger.l_onoff=1;//(在closesocket()調(diào)用,可是還有數(shù)據(jù)沒(méi)發(fā)送完畢的時(shí)候容許逗留)
// 假設(shè)m_sLinger.l_onoff=0;則功能和2.)作用同樣;
m_sLinger.l_linger=5;//(容許逗留的時(shí)間為5秒)
setsockopt(s,SOL_SOCKET,SO_LINGER,(const char*)&m_sLinger,sizeof(linger)); setsockopt()使用方法 2007/12/05 19:01
| 一下來(lái)源于互聯(lián)網(wǎng)： 1.closesocket（一般不會(huì)馬上關(guān)閉而經(jīng)歷TIME_WAIT的過(guò)程）后想繼續(xù)重用該socket： 2. 假設(shè)要已經(jīng)處于連接狀態(tài)的soket在調(diào)用closesocket后強(qiáng)制關(guān)閉，不經(jīng)歷 3.在send(),recv()過(guò)程中有時(shí)因?yàn)榫W(wǎng)絡(luò)狀況等原因，發(fā)收不能預(yù)期進(jìn)行,而設(shè)置收發(fā)時(shí)限： 4.在send()的時(shí)候，返回的是實(shí)際發(fā)送出去的字節(jié)(同步)或發(fā)送到socket緩沖區(qū)的字節(jié)
|
總結(jié)
以上是生活随笔為你收集整理的setsockopt()使用方法（參数具体说明）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： C++ Primer 学习笔记_75_模
- 下一篇： 公司的实战Replica Sets+Sh