Java Socket的api可能不少人會用,可是Java Socket的參數可能不少人都不知道用來幹嗎的,甚至都不知道有這些參數。java
backlog
用於ServerSocket,配置ServerSocket的最大客戶端等待隊列。等待隊列的意思,先看下面代碼算法
public class Main {
public static void main(String[] args) throws Exception {
int port = 8999;
int backlog = 2;
ServerSocket serverSocket = new ServerSocket(port, backlog);
Socket clientSock = serverSocket.accept();
System.out.println("revcive from " + clientSock.getPort());
while (true) {
byte buf[] = new byte[1024];
int len = clientSock.getInputStream().read(buf);
System.out.println(new String(buf, 0, len));
}
}
}
這段測試代碼在第一次處理一個客戶端時,就不會處理第二個客戶端,因此除了第一個客戶端,其餘客戶端就是等待隊列了。因此這個服務器最多能夠同時鏈接3個客戶端,其中2個等待隊列。你們能夠telnet localhost 8999測試下。
這個參數設置爲-1表示無限制,默認是50個最大等待隊列,若是設置無限制,那麼你要當心了,若是你服務器沒法處理那麼多鏈接,那麼當不少客戶端連到你的服務器時,每個TCP鏈接都會佔用服務器的內存,最後會讓服務器崩潰的。
另外,就算你設置了backlog爲10,若是你的代碼中是一直Socket clientSock = serverSocket.accept(),假設咱們的機器最多能夠同時處理100個請求,總共有100個線程在運行,而後你把在100個線程的線程池處理clientSock,不能處理的clientSock就排隊,最後clientSock愈來愈多,也意味着TCP鏈接愈來愈多,也意味着咱們的服務器的內存使用愈來愈高(客戶端鏈接進程,確定會發送數據過來,數據會保存到服務器端的TCP接收緩存區),最後服務器就宕機了。因此若是你不能處理那麼多請求,請不要循環無限制地調用serverSocket.accept(),不然backlog也沒法生效。若是真的請求過多,只會讓你的服務器宕機(相信不少人都是這麼寫,要注意點)
TcpNoDelay
禁用納格算法,將數據當即發送出去。納格算法是以減小封包傳送量來增進TCP/IP網絡的效能,當咱們調用下面代碼,如:
Socket socket = new Socket();
socket.connect(new InetSocketAddress(host, 8000));
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
String head = "hello ";
String body = "world\r\n";
out.write(head.getBytes());
out.write(body.getBytes());
咱們發送了hello,當hello沒有收到ack確認(TCP是可靠鏈接,發送的每個數據都要收到對方的一個ack確認,不然就要重發)的時候,根據納格算法,world不會立馬發送,會等待,要麼等到ack確認(最多等100ms對方會發過來的),要麼等到TCP緩衝區內容>=MSS,很明顯這裏沒有機會,咱們寫了world後再也沒有寫數據了,因此只能等到hello的ack咱們纔會發送world,除非咱們禁用納格算法,數據就會當即發送了。
另外有一篇講解納格算法和delay ack的文章(挺不錯的):http://blog.csdn.net/frankggyy/article/details/6624401
SoLinger
當咱們調用socket.close()返回時,socket已經write的數據未必已經發送到對方了,例如
Socket socket = new Socket();
socket.connect(new InetSocketAddress(host, 8000));
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
String head = "hello ";
String body = "world\r\n";
out.write(head.getBytes());
out.write(body.getBytes());
socket.close();
這裏調用了socket.close()返回時,hello和world未必已經成功發送到對方了,若是咱們設置了linger而不小於0,如:
bool on = true;
int linger = 100;
....
socket.setSoLinger(boolean on, int linger)
......
socket.close();
那麼close會等到發送的數據已經確認了才返回。可是若是對方宕機,超時,那麼會根據linger設定的時間返回。
UrgentData和OOBInline
TCP的緊急指針,通常都不建議使用,並且不一樣的TCP/IP實現,也不一樣,通常說若是你有緊急數據寧願再創建一個新的TCP/IP鏈接發送數據,讓對方緊急處理。
因此這兩個參數,大家能夠忽略吧,想知道更多的,本身查下資料。
SoTimeout
設置socket調用InputStream讀數據的超時時間,以毫秒爲單位,若是超過這個時候,會拋出java.net.SocketTimeoutException。
KeepAlive
keepalive不是說TCP的常鏈接,當咱們做爲服務端,一個客戶端鏈接上來,若是設置了keeplive爲true,當對方沒有發送任何數據過來,超過一個時間(看系統內核參數配置),那麼咱們這邊會發送一個ack探測包發到對方,探測雙方的TCP/IP鏈接是否有效(對方可能斷點,斷網),在Linux好像這個時間是75秒。若是不設置,那麼客戶端宕機時,服務器永遠也不知道客戶端宕機了,仍然保存這個失效的鏈接。
SendBufferSize和ReceiveBufferSize
TCP發送緩存區和接收緩存區,默認是8192,通常狀況下足夠了,並且就算你增長了發送緩存區,對方沒有增長它對應的接收緩衝,那麼在TCP三握手時,最後肯定的最大發送窗口仍是雙方最小的那個緩衝區,就算你無視,發了更多的數據,那麼多出來的數據也會被丟棄。除非雙方都協商好。
以上的參數都是比較重要的Java Socket參數了,其餘就不另外說明了。
版權聲明:本文爲博主原創文章,未經博主容許不得轉載。api