TCP是基于流的，客戶端發(fā)送的請求數(shù)據(jù)是像水流一樣流入到服務端，服務端探測到有數(shù)據(jù)到來后應該檢查數(shù)據(jù)是否是完整的，因為可能只是一個請求的部分數(shù)據(jù)到達服務端，甚至可能是多個請求連在一起到達服務端。如何判斷請求是否全部到達或者從多個連在一起的請求中分離請求，就需要規(guī)定一套通訊協(xié)議。

參考http://doc3.workerman.net/protocols/why-protocols.html。

沒有多個數(shù)據(jù)請求，只有一個請求都不行。只上傳一張圖片都不行

上面沒有說一定是多個請求才會出現(xiàn)這種情況。這個是TCP的機制，是正常的。

TCP是基于流的，客戶端發(fā)送的請求數(shù)據(jù)是像水流一樣流入到服務端，服務端探測到有數(shù)據(jù)到來后應該檢查數(shù)據(jù)是否是完整的，因為可能只是一個請求的部分數(shù)據(jù)到達服務端

比如上傳了一個文件，文件是一點一點上傳到服務端的，如果沒有設置通訊協(xié)議，服務端每收到數(shù)據(jù)都會觸發(fā)onMessage，但是onMessage里的數(shù)據(jù)只是部分數(shù)據(jù)，需要把這些數(shù)據(jù)組裝起來才是完整的數(shù)據(jù)。

如果設置了應用層通訊協(xié)議，服務端會根據(jù)協(xié)議規(guī)則判斷這個文件有多大，然后每收到部分數(shù)據(jù)就將它們緩沖并拼接起來，直到收到全部數(shù)據(jù)，然后觸發(fā)onMessage，這樣設置了通訊協(xié)議后onMessage里的文件就是完整的了。
例如用http協(xié)議上傳一個文件，根據(jù)http協(xié)議規(guī)則，http包的頭部會包含這個文件的大小，服務端根據(jù)規(guī)則讀取這個大小，然后將每次收到的一點數(shù)據(jù)拼接起來，最后組成一個完整的http請求，包體是文件數(shù)據(jù)，并觸發(fā)onMessage，得到完整的文件數(shù)據(jù)。

參考http://doc3.workerman.net/protocols/why-protocols.html。

上傳一個1M的圖片都接收不了

其實都收到了，只是你不愿意看手冊，不愿仔細看我上面的回復，自己又不會用而已