※ 引述《Killercat (殺人貓™)》之銘言： : 這個有一個小例外，不過因為太常碰到了，所以回文講一下 : 我們有時候會有些需求，要用socket對HTTP做手腳，發request/收recv : HTTP1.0的時候，server傳完[header]\r\n\r\n[body]就會很乖的把它斷開 : (這個上面看不懂的其實下面也不太需要浪費時間看了，因為這代表沒碰過這需求 : 等到實際碰到再回來看就可以了) : 所以socket.getInputStream()會很乖的如上面所說的斷開 : 當然，HTTP版本是可以從request的header去指定的 : HTTP1.1的時候情況就不一樣了，除了比以前1.0多要求了一個Host header以外， : 還多增加了一個叫做Connection的Header。這個Connection header很妙 : 他預設是keep-alive : Connection: keep-alive : 這個keep-alive會keep住這個session讓他不會斷開，即使資料傳完了也一樣 : 按標準的話印象中是要20秒沒資料來回才會斷開，那這個socket.getInputStream() : 問題就很大了...因為他不會自己斷，你也不該自己斷，這單單用socket其實頗難處理的 : 如果要讓他能像以前的行為一樣斷開的話，你必須把Connection指定為closed : Connection: closed : 為什麼預設是keep-alive以及為什麼要支援keep-alive這個就不在本文討論範圍之內了， : 總之在某些情況下Socket.getInputStream()的確在讀完了並不會斷開 : 可是，這篇不是講FileInputStream嗎？ : 這就是重點了，FileInputStream的spec中並沒有eof會斷開的規定，任何設備商 : 要是以pipe來傳遞，而且overload FileInputStream的話，其實是有絕對的能力 : 去讓他read卡在那裡讀不到東西卻不直接執行斷開的，而且這種東西實作上是很 : 有可能發生的，端看廠商怎麼實作。 我覺得這一篇提到“特列”似乎與原本討論的主題沒有直接的關聯， 而基本上 EOF 與 stream 斷掉是不同的一件事。 EOF 是表示再也沒有更多的 data，到達 EOF 不代表 stream close，儘管 Java OutputStream 沒有定義送出 EOF 的操作，目前只能以 close stream 的方式去 達到通知接收端 EOF 的作用，但是考慮到 stream 的另一端可以是任意的 軟體與設備，我覺得還是要把 EOF 與 stream closed 當做兩個不同的概念。 文中提到的 HTTP request 的 Connection: Keep-Alive header 是為了讓 client 可以重復利用一個 socket connection 送出多個 HTTP request 給 server，所以 server 當然不能吐完 response body 後就 close stream/connection。 通常會懂得使用 persistent connection 的人一定會知道要從 response header: Content-Length 來判斷 server 送出來的 body 長度(即使不使用 persistent connection 有時也會去看看 Content-Length)，不會只依賴 stream EOF。 至於最後提到 read 卡住，沒有 EOF 也沒有斷掉 stream，有些是沒辦法確認 end of stream 這件事成立，例如透過硬體上的實體連接線與外部交換資料( Serial port 等等)，而不是沒有實做好。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.172.241.69