int setsockopt(
SOCKET s,
int level,
int optname,
const char* optval,
int optlen
);
s(套接字): 指向一個打開的套接口描述字
level:(級別)： 指定選項代碼的類型。
SOL_SOCKET: 基本套接口
IPPROTO_IP: IPv4套接口
IPPROTO_IPV6: IPv6套接口
IPPROTO_TCP: TCP套接口
optname(選項名)： 選項名稱
optval(選項值): 是一個指向變量的指針 類型：整形，套接口結(jié)構(gòu)， 其他結(jié)構(gòu)類型:linger{}, timeval{ }
optlen(選項長度) ：optval 的大小
返回值：標志打開或關(guān)閉某個特征的二進制選項
[/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 獲得套接字錯誤 int
SO_KEEPALIVE 保持連接 int
檢測對方主機是否崩潰，避免（服務(wù)器）永遠阻塞于TCP連接的輸入。 設(shè)置該選項后，如果2小時內(nèi)在此套接口的任一方向都沒有數(shù)據(jù)交換，TCP就自動給對方 發(fā)一個保持存活探測分節(jié)(keepalive probe)。這是一個對方必須響應(yīng)的TCP分節(jié).它會導(dǎo)致以下三種情況： 對方接收一切正常：以期望的ACK響應(yīng)。2小時后，TCP將發(fā)出另一個探測分節(jié)。 對方已崩潰且已重新啟動：以RST響應(yīng)。套接口的待處理錯誤被置為ECONNRESET，套接 口本身則被關(guān)閉。 對方無任何響應(yīng)：源自berkeley的TCP發(fā)送另外8個探測分節(jié)，相隔75秒一個，試圖得到 一個響應(yīng)。在發(fā)出第一個探測分節(jié)11分鐘15秒后若仍無響應(yīng)就放棄。套接口的待處理錯 誤被置為ETIMEOUT，套接口本身則被關(guān)閉。如ICMP錯誤是“host unreachable(主機不 可達)”，說明對方主機并沒有崩潰，但是不可達，這種情況下待處理錯誤被置為 EHOSTUNREACH。
SO_DONTLINGER 若為真，則SO_LINGER選項被禁止。
SO_LINGER 延遲關(guān)閉連接 struct linger
上面這兩個選項影響close行為
選項 間隔 關(guān)閉方式 等待關(guān)閉與否
SO_DONTLINGER 不關(guān)心 優(yōu)雅 否
SO_LINGER 零 強制 否
SO_LINGER 非零 優(yōu)雅 是
若設(shè)置了SO_LINGER（亦即linger結(jié)構(gòu)中的l_onoff域設(shè)為非零，參見2.4，4.1.7和4.1.21各節(jié)），并設(shè)置了零超時間隔，則closesocket()不被阻塞立即執(zhí)行，不論是否有排隊數(shù)據(jù)未發(fā)送或未被確認。這種關(guān)閉方式稱為“強制”或“失效”關(guān)閉，因為套接口的虛電路立即被復(fù)位，且丟失了未發(fā)送的數(shù)據(jù)。在遠端的recv()調(diào)用將以WSAECONNRESET出錯。
若設(shè)置了SO_LINGER并確定了非零的超時間隔，則closesocket()調(diào)用阻塞進程，直到所剩數(shù)據(jù)發(fā)送完畢或超時。這種關(guān)閉稱為“優(yōu)雅的”關(guān)閉。請注意如果套接口置為非阻塞且SO_LINGER設(shè)為非零超時，則closesocket()調(diào)用將以WSAEWOULDBLOCK錯誤返回。
若在一個流類套接口上設(shè)置了SO_DONTLINGER（也就是說將linger結(jié)構(gòu)的l_onoff域設(shè)為零；參見2.4，4.1.7，4.1.21節(jié)），則closesocket()調(diào)用立即返回。但是，如果可能，排隊的數(shù)據(jù)將在套接口關(guān)閉前發(fā)送。請注意，在這種情況下WINDOWS套接口實現(xiàn)將在一段不確定的時間內(nèi)保留套接口以及其他資源，這對于想用所以套接口的應(yīng)用程序來說有一定影響。
SO_OOBINLINE 帶外數(shù)據(jù)放入正常數(shù)據(jù)流,在普通數(shù)據(jù)流中接收帶外數(shù)據(jù) int
SO_RCVBUF 接收緩沖區(qū)大小 int
設(shè)置接收緩沖區(qū)的保留大小
與 SO_MAX_MSG_SIZE 或TCP滑動窗口無關(guān)，如果一般發(fā)送的包很大很頻繁，那么使用這個選項
SO_SNDBUF 發(fā)送緩沖區(qū)大小 int
設(shè)置發(fā)送緩沖區(qū)的保留大小
與 SO_MAX_MSG_SIZE 或TCP滑動窗口無關(guān)，如果一般發(fā)送的包很大很頻繁，那么使用這個選項
每個套接口都有一個發(fā)送緩沖區(qū)和一個接收緩沖區(qū)。 接收緩沖區(qū)被TCP和UDP用來將接收到的數(shù)據(jù)一直保存到由應(yīng)用進程來讀。 TCP：TCP通告另一端的窗口大小。 TCP套接口接收緩沖區(qū)不可能溢出，因為對方不允許發(fā)出超過所通告窗口大小的數(shù)據(jù)。 這就是TCP的流量控制，如果對方無視窗口大小而發(fā)出了超過宙口大小的數(shù)據(jù)，則接 收方TCP將丟棄它。 UDP：當(dāng)接收到的數(shù)據(jù)報裝不進套接口接收緩沖區(qū)時，此數(shù)據(jù)報就被丟棄。UDP是沒有 流量控制的；快的發(fā)送者可以很容易地就淹沒慢的接收者，導(dǎo)致接收方的UDP丟棄數(shù)據(jù)報。
SO_RCVLOWAT 接收緩沖區(qū)下限 int
SO_SNDLOWAT 發(fā)送緩沖區(qū)下限 int
每個套接口都有一個接收低潮限度和一個發(fā)送低潮限度。它們是函數(shù)selectt使用的， 接收低潮限度是讓select返回“可讀”而在套接口接收緩沖區(qū)中必須有的數(shù)據(jù)總量。 ——對于一個TCP或UDP套接口，此值缺省為1。發(fā)送低潮限度是讓select返回“可寫” 而在套接口發(fā)送緩沖區(qū)中必須有的可用空間。對于TCP套接口，此值常缺省為2048。 對于UDP使用低潮限度， 由于其發(fā)送緩沖區(qū)中可用空間的字節(jié)數(shù)是從不變化的，只要 UDP套接口發(fā)送緩沖區(qū)大小大于套接口的低潮限度，這樣的UDP套接口就總是可寫的。 UDP沒有發(fā)送緩沖區(qū)，只有發(fā)送緩沖區(qū)的大小。
SO_RCVTIMEO 接收超時 struct timeval
SO_SNDTIMEO 發(fā)送超時 struct timeval
SO_REUSERADDR 允許重用本地地址和端口 int
充許綁定已被使用的地址（或端口號），可以參考bind的man
SO_EXCLUSIVEADDRUSE
獨占模式使用端口,就是不充許和其它程序使用SO_REUSEADDR共享的使用某一端口。
在確定多重綁定使用誰的時候，根據(jù)一條原則是誰的指定最明確則將包遞交給誰，而且沒有權(quán)限之分，也就是說低級權(quán)限的用戶是可以重綁定在高級權(quán)限如服務(wù)啟動的端口上的,這是非常重大的一個安全隱患,
如果不想讓自己程序被監(jiān)聽，那么使用這個選項
SO_TYPE 獲得套接字類型 int
SO_BSDCOMPAT 與BSD系統(tǒng)兼容 int
==========================================================================
IPPROTO_IP
--------------------------------------------------------------------------
IP_HDRINCL 在數(shù)據(jù)包中包含IP首部 int
這個選項常用于黑客技術(shù)中，隱藏自己的IP地址
IP_OPTINOS IP首部選項 int
IP_TOS 服務(wù)類型
IP_TTL 生存時間 int
以下IPV4選項用于組播
IPv4 選項 數(shù)據(jù)類型 描 述
IP_ADD_MEMBERSHIP struct ip_mreq 加入到組播組中
IP_ROP_MEMBERSHIP struct ip_mreq 從組播組中退出
IP_MULTICAST_IF struct ip_mreq 指定提交組播報文的接口
IP_MULTICAST_TTL u_char 指定提交組播報文的TTL
IP_MULTICAST_LOOP u_char 使組播報文環(huán)路有效或無效
在頭文件中定義了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]
若進程要加入到一個組播組中，用soket的setsockopt()函數(shù)發(fā)送該選項。該選項類型是ip_mreq結(jié)構(gòu)，它的第一個字段imr_multiaddr指定了組播組的地址，第二個字段imr_interface指定了接口的IPv4地址。
IP_DROP_MEMBERSHIP
該選項用來從某個組播組中退出。數(shù)據(jù)結(jié)構(gòu)ip_mreq的使用方法與上面相同。
IP_MULTICAST_IF
該選項可以修改網(wǎng)絡(luò)接口，在結(jié)構(gòu)ip_mreq中定義新的接口。
IP_MULTICAST_TTL
設(shè)置組播報文的數(shù)據(jù)包的TTL（生存時間）。默認值是1，表示數(shù)據(jù)包只能在本地的子網(wǎng)中傳送。
IP_MULTICAST_LOOP
組播組中的成員自己也會收到它向本組發(fā)送的報文。這個選項用于選擇是否激活這種狀態(tài)。
|
無雙 回復(fù)于：2003-05-08
21:21:52 |
IPPRO_TCP
--------------------------------------------------------------------------
TCP_MAXSEG TCP最大數(shù)據(jù)段的大小 int
獲取或設(shè)置TCP連接的最大分節(jié)大小(MSS)。返回值是我們的TCP發(fā)送給另一端的最大 數(shù)據(jù)量，它常常就是由另一端用SYN分節(jié)通告的MSS，除非我們的TCP選擇使用一個比 對方通告的MSS小些的值。如果此值在套接口連接之前取得，則返回值為未從另·—端 收到Mss選項的情況下所用的缺省值。小于此返回值的信可能真正用在連接上，因為譬 如說使用時間戳選項的話，它在每個分節(jié)上占用12字節(jié)的TCP選項容量。我們的TcP將 發(fā)送的每個分節(jié)的最大數(shù)據(jù)量也可在連接存活期內(nèi)改變，但前提是TCP要支持路徑MTU 發(fā)現(xiàn)功能。如果到對方的路徑改變了，此值可上下調(diào)整。
TCP_NODELAY 不使用Nagle算法 int
指定TCP開始發(fā)送保持存活探測分節(jié)前以秒為單位的連接空閑時間。缺省值至少必須為7200秒，即2小時。此選項僅在SO_KEPALIVEE套接口選項打開時才有效。
TCP_NODELAY 和 TCP_CORK，
這兩個選項都對網(wǎng)絡(luò)連接的行為具有重要的作用。許多UNIX系統(tǒng)都實現(xiàn)了TCP_NODELAY選項，但是，TCP_CORK則是Linux系統(tǒng)所獨有的而且相對較新；它首先在內(nèi)核版本2.4上得以實現(xiàn)。此外，其他UNIX系統(tǒng)版本也有功能類似的選項，值得注意的是，在某種由BSD派生的系統(tǒng)上的TCP_NOPUSH選項其實就是TCP_CORK的一部分具體實現(xiàn)。
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在這里的含義是采用Nagle算法把較小的包組裝為更大的幀。John Nagle是Nagle算法的發(fā)明人，后者就是用他的名字來命名的，他在1984年首次用這種方法來嘗試解決福特汽車公司的網(wǎng)絡(luò)擁塞問題（欲了解詳情請參看IETF RFC 896）。他解決的問題就是所謂的silly window syndrome ，中文稱“愚蠢窗口癥候群”，具體含義是，因為普遍終端應(yīng)用程序每產(chǎn)生一次擊鍵操作就會發(fā)送一個包，而典型情況下一個包會擁有一個字節(jié)的數(shù)據(jù)載荷以及40個字節(jié)長的包頭，于是產(chǎn)生4000%的過載，很輕易地就能令網(wǎng)絡(luò)發(fā)生擁塞,。 Nagle化后來成了一種標準并且立即在因特網(wǎng)上得以實現(xiàn)。它現(xiàn)在已經(jīng)成為缺省配置了，但在我們看來，有些場合下把這一選項關(guān)掉也是合乎需要的。
現(xiàn)在讓我們假設(shè)某個應(yīng)用程序發(fā)出了一個請求，希望發(fā)送小塊數(shù)據(jù)。我們可以選擇立即發(fā)送數(shù)據(jù)或者等待產(chǎn)生更多的數(shù)據(jù)然后再一次發(fā)送兩種策略。如果我們馬上發(fā)送數(shù)據(jù)，那么交互性的以及客戶/服務(wù)器型的應(yīng)用程序?qū)O大地受益。例如，當(dāng)我們正在發(fā)送一個較短的請求并且等候較大的響應(yīng)時，相關(guān)過載與傳輸?shù)臄?shù)據(jù)總量相比就會比較低，而且，如果請求立即發(fā)出那么響應(yīng)時間也會快一些。以上操作可以通過設(shè)置套接字的TCP_NODELAY選項來完成，這樣就禁用了Nagle算法。
另外一種情況則需要我們等到數(shù)據(jù)量達到最大時才通過網(wǎng)絡(luò)一次發(fā)送全部數(shù)據(jù)，這種數(shù)據(jù)傳輸方式有益于大量數(shù)據(jù)的通信性能，典型的應(yīng)用就是文件服務(wù)器。應(yīng)用Nagle算法在這種情況下就會產(chǎn)生問題。但是，如果你正在發(fā)送大量數(shù)據(jù)，你可以設(shè)置TCP_CORK選項禁用Nagle化，其方式正好同TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就讓我們仔細分析下其工作原理。
假設(shè)應(yīng)用程序使用sendfile()函數(shù)來轉(zhuǎn)移大量數(shù)據(jù)。應(yīng)用協(xié)議通常要求發(fā)送某些信息來預(yù)先解釋數(shù)據(jù)，這些信息其實就是報頭內(nèi)容。典型情況下報頭很小，而且套接字上設(shè)置了TCP_NODELAY。有報頭的包將被立即傳輸，在某些情況下（取決于內(nèi)部的包計數(shù)器），因為這個包成功地被對方收到后需要請求對方確認。這樣，大量數(shù)據(jù)的傳輸就會被推遲而且產(chǎn)生了不必要的網(wǎng)絡(luò)流量交換。
但是，如果我們在套接字上設(shè)置了TCP_CORK（可以比喻為在管道上插入“塞子”）選項，具有報頭的包就會填補大量的數(shù)據(jù)，所有的數(shù)據(jù)都根據(jù)大小自動地通過包傳輸出去。當(dāng)數(shù)據(jù)傳輸完成時，最好取消TCP_CORK 選項設(shè)置給連接“拔去塞子”以便任一部分的幀都能發(fā)送出去。這同“塞住”網(wǎng)絡(luò)連接同等重要。
總而言之，如果你肯定能一起發(fā)送多個數(shù)據(jù)集合（例如HTTP響應(yīng)的頭和正文），那么我們建議你設(shè)置TCP_CORK選項，這樣在這些數(shù)據(jù)之間不存在延遲。能極大地有益于WWW、FTP以及文件服務(wù)器的性能，同時也簡化了你的工作。示例代碼如下：
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)); /* 拔去塞子 */
不幸的是，許多常用的程序并沒有考慮到以上問題。例如，Eric Allman編寫的sendmail就沒有對其套接字設(shè)置任何選項。
Apache HTTPD是因特網(wǎng)上最流行的Web服務(wù)器，它的所有套接字就都設(shè)置了TCP_NODELAY選項，而且其性能也深受大多數(shù)用戶的滿意。這是為什么呢？答案就在于實現(xiàn)的差別之上。由BSD衍生的TCP/IP協(xié)議棧（值得注意的是FreeBSD）在這種狀況下的操作就不同。當(dāng)在TCP_NODELAY 模式下提交大量小數(shù)據(jù)塊傳輸時，大量信息將按照一次write()函數(shù)調(diào)用發(fā)送一塊數(shù)據(jù)的方式發(fā)送出去。然而，因為負責(zé)請求交付確認的記數(shù)器是面向字節(jié)而非面向包（在Linux上）的，所以引入延遲的概率就降低了很多。結(jié)果僅僅和全部數(shù)據(jù)的大小有關(guān)系。而 Linux 在第一包到達之后就要求確認，F(xiàn)reeBSD則在進行如此操作之前會等待好幾百個包。
在Linux系統(tǒng)上，TCP_NODELAY的效果同習(xí)慣于BSD TCP/IP協(xié)議棧的開發(fā)者所期望的效果有很大不同，而且在Linux上的Apache性能表現(xiàn)也會更差些。其他在Linux上頻繁采用TCP_NODELAY的應(yīng)用程序也有同樣的問題。
TCP_DEFER_ACCEPT
我們首先考慮的第1個選項是TCP_DEFER_ACCEPT（這是Linux系統(tǒng)上的叫法，其他一些操作系統(tǒng)上也有同樣的選項但使用不同的名字）。為了理解TCP_DEFER_ACCEPT選項的具體思想，我們有必要大致闡述一下典型的HTTP客戶/服務(wù)器交互過程。請回想下TCP是如何與傳輸數(shù)據(jù)的目標建立連接的。在網(wǎng)絡(luò)上，在分離的單元之間傳輸?shù)男畔⒎Q為IP包（或IP 數(shù)據(jù)報）。一個包總有一個攜帶服務(wù)信息的包頭，包頭用于內(nèi)部協(xié)議的處理，并且它也可以攜帶數(shù)據(jù)負載。服務(wù)信息的典型例子就是一套所謂的標志，它把包標記代表TCP/IP協(xié)議棧內(nèi)的特殊含義，例如收到包的成功確認等等。通常，在經(jīng)過“標記”的包里攜帶負載是完全可能的，但有時，內(nèi)部邏輯迫使TCP/IP協(xié)議棧發(fā)出只有包頭的IP包。這些包經(jīng)常會引發(fā)討厭的網(wǎng)絡(luò)延遲而且還增加了系統(tǒng)的負載，結(jié)果導(dǎo)致網(wǎng)絡(luò)性能在整體上降低。
現(xiàn)在服務(wù)器創(chuàng)建了一個套接字同時等待連接。TCP/IP式的連接過程就是所謂“3次握手”。首先，客戶程序發(fā)送一個設(shè)置SYN標志而且不帶數(shù)據(jù)負載的TCP包（一個SYN包）。服務(wù)器則以發(fā)出帶SYN/ACK標志的數(shù)據(jù)包（一個SYN/ACK包）作為剛才收到包的確認響應(yīng)。客戶隨后發(fā)送一個ACK包確認收到了第2個包從而結(jié)束連接過程。在收到客戶發(fā)來的這個SYN/ACK包之后，服務(wù)器會喚醒一個接收進程等待數(shù)據(jù)到達。當(dāng)3次握手完成后，客戶程序即開始把“有用的”的數(shù)據(jù)發(fā)送給服務(wù)器。通常，一個HTTP請求的量是很小的而且完全可以裝到一個包里。但是，在以上的情況下，至少有4個包將用來進行雙向傳輸，這樣就增加了可觀的延遲時間。此外，你還得注意到，在“有用的”數(shù)據(jù)被發(fā)送之前，接收方已經(jīng)開始在等待信息了。
為了減輕這些問題所帶來的影響，Linux（以及其他的一些操作系統(tǒng)）在其TCP實現(xiàn)中包括了TCP_DEFER_ACCEPT選項。它們設(shè)置在偵聽套接字的服務(wù)器方，該選項命令內(nèi)核不等待最后的ACK包而且在第1個真正有數(shù)據(jù)的包到達才初始化偵聽進程。在發(fā)送SYN/ACK包之后，服務(wù)器就會等待客戶程序發(fā)送含數(shù)據(jù)的IP包。現(xiàn)在，只需要在網(wǎng)絡(luò)上傳送3個包了，而且還顯著降低了連接建立的延遲，對HTTP通信而言尤其如此。
這一選項在好些操作系統(tǒng)上都有相應(yīng)的對等物。例如，在FreeBSD上，同樣的行為可以用以下代碼實現(xiàn)：
/* 為明晰起見，此處略去無關(guān)代碼 */
struct accept_filter_arg af = { "dataready", "" };
setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af));
這個特征在FreeBSD上叫做“接受過濾器”，而且具有多種用法。不過，在幾乎所有的情況下其效果與TCP_DEFER_ACCEPT是一樣的：服務(wù)器不等待最后的ACK包而僅僅等待攜帶數(shù)據(jù)負載的包。要了解該選項及其對高性能Web服務(wù)器的重要意義的更多信息請參考Apache文檔上的有關(guān)內(nèi)容。
就HTTP客戶/服務(wù)器交互而言，有可能需要改變客戶程序的行為。客戶程序為什么要發(fā)送這種“無用的”ACK包呢？這是因為，TCP協(xié)議棧無法知道ACK包的狀態(tài)。如果采用FTP而非HTTP，那么客戶程序直到接收了FTP服務(wù)器提示的數(shù)據(jù)包之后才發(fā)送數(shù)據(jù)。在這種情況下，延遲的ACK將導(dǎo)致客戶/服務(wù)器交互出現(xiàn)延遲。為了確定ACK是否必要，客戶程序必須知道應(yīng)用程序協(xié)議及其當(dāng)前狀態(tài)。這樣，修改客戶行為就成為必要了。
對Linux客戶程序來說，我們還可以采用另一個選項，它也被叫做TCP_DEFER_ACCEPT。我們知道，套接字分成兩種類型，偵聽套接字和連接套接字，所以它們也各自具有相應(yīng)的TCP選項集合。因此，經(jīng)常同時采用的這兩類選項卻具有同樣的名字也是完全可能的。在連接套接字上設(shè)置該選項以后，客戶在收到一個SYN/ACK包之后就不再發(fā)送ACK包，而是等待用戶程序的下一個發(fā)送數(shù)據(jù)請求；因此，服務(wù)器發(fā)送的包也就相應(yīng)減少了。
TCP_QUICKACK
阻止因發(fā)送無用包而引發(fā)延遲的另一個方法是使用TCP_QUICKACK選項。這一選項與 TCP_DEFER_ACCEPT不同，它不但能用作管理連接建立過程而且在正常數(shù)據(jù)傳輸過程期間也可以使用。另外，它能在客戶/服務(wù)器連接的任何一方設(shè)置。如果知道數(shù)據(jù)不久即將發(fā)送，那么推遲ACK包的發(fā)送就會派上用場，而且最好在那個攜帶數(shù)據(jù)的數(shù)據(jù)包上設(shè)置ACK 標志以便把網(wǎng)絡(luò)負載減到最小。當(dāng)發(fā)送方肯定數(shù)據(jù)將被立即發(fā)送（多個包）時，TCP_QUICKACK選項可以設(shè)置為0。對處于“連接”狀態(tài)下的套接字該選項的缺省值是1，首次使用以后內(nèi)核將把該選項立即復(fù)位為1（這是個一次性的選項）。
在某些情形下，發(fā)出ACK包則非常有用。ACK包將確認數(shù)據(jù)塊的接收，而且，當(dāng)下一塊被處理時不至于引入延遲。這種數(shù)據(jù)傳輸模式對交互過程是相當(dāng)?shù)湫偷模驗榇祟惽闆r下用戶的輸入時刻無法預(yù)測。在Linux系統(tǒng)上這就是缺省的套接字行為。
在上述情況下，客戶程序在向服務(wù)器發(fā)送HTTP請求，而預(yù)先就知道請求包很短所以在連接建立之后就應(yīng)該立即發(fā)送，這可謂HTTP的典型工作方式。既然沒有必要發(fā)送一個純粹的ACK包，所以設(shè)置TCP_QUICKACK為0以提高性能是完全可能的。在服務(wù)器方，這兩種選項都只能在偵聽套接字上設(shè)置一次。所有的套接字，也就是被接受呼叫間接創(chuàng)建的套接字則會繼承原有套接字的所有選項。
通過TCP_CORK、TCP_DEFER_ACCEPT和TCP_QUICKACK選項的組合，參與每一HTTP交互的數(shù)據(jù)包數(shù)量將被降低到最小的可接受水平（根據(jù)TCP協(xié)議的要求和安全方面的考慮）。結(jié)果不僅是獲得更快的數(shù)據(jù)傳輸和請求處理速度而且還使客戶/服務(wù)器雙向延遲實現(xiàn)了最小化。
|
posted on 2009-07-29 08:33
yunboy 閱讀(3658)
評論(0) 編輯 收藏 引用 所屬分類:
網(wǎng)絡(luò)通信