肯定是TCP協(xié)議，應(yīng)用層的協(xié)議也都以此為基礎(chǔ)。Http也支持長連接，但是Http只是應(yīng)用層協(xié)議，傳輸層依然是TCP，優(yōu)點是節(jié)省建立連接和關(guān)閉連接的開銷，缺點是要一直維護(hù)這個連接，我們常說的長連接，通常是指傳輸層的使用TCP協(xié)議經(jīng)過三次握手建立的連接。

1、長連接的實質(zhì)是什么？用什么協(xié)議比較好？如何優(yōu)化？

謝邀~常年做Java開發(fā)，對網(wǎng)絡(luò)編程也有一定的了解，下面我分享一下自己的看法；如果認(rèn)識有不對的地方，請大家留言指正。長連接、短連接的定義長連接：建立好連接后，不關(guān)閉連接，一直保持通訊狀態(tài)，當(dāng)后續(xù)再有數(shù)據(jù)需要傳輸?shù)臅r候，就已經(jīng)建立好的連接即可，優(yōu)點是節(jié)省建立連接和關(guān)閉連接的開銷，缺點是要一直維護(hù)這個連接。

短連接：每次數(shù)據(jù)傳輸?shù)臅r候，都需要建立一個新的連接，數(shù)據(jù)傳輸完就關(guān)閉連接，長連接的實質(zhì)/實現(xiàn)長連接的實質(zhì)，我也在考慮怎么說比較合適，題主問題中的描述，我覺得叫做長連接的實現(xiàn)比較合適（Socket本質(zhì)是編程接口API，對TCP/IP的封裝，它本身不是協(xié)議）。理解這個問題，首要要了解下TCP/IP模型，我們主要看傳輸層和應(yīng)用層，

傳輸層包含我們最常見的：TCP、UDP。應(yīng)用層常見的：Http、Https、SMTP、FTP等等，很多，Socket和TCP/IP沒啥實質(zhì)關(guān)系，它就是對TCP/IP進(jìn)行了抽象和封裝，形成了函數(shù)接口，程序員使用起來很方便。我們常說的長連接，通常是指傳輸層的使用TCP協(xié)議經(jīng)過三次握手建立的連接，心跳是保持長連接的手段，在TCP中，就是KeepAlive機(jī)制。

長連接使用什么協(xié)議？肯定是TCP協(xié)議，應(yīng)用層的協(xié)議也都以此為基礎(chǔ)，Http也支持長連接，但是Http只是應(yīng)用層協(xié)議，傳輸層依然是TCP。長連接的優(yōu)化長連接最大的缺點，就是建立好連接之后，就要不斷地維護(hù)這個連接，并且長連接會加重服務(wù)器的負(fù)擔(dān)，優(yōu)化心跳機(jī)制，每次業(yè)務(wù)數(shù)據(jù)請求也看做一次心跳，減少無效的數(shù)據(jù)傳輸。

2、三方協(xié)議是什么？簽三方或不簽各有什么優(yōu)缺點？

三方協(xié)議，就是三個參與者甲、乙、丙共同就某一件事情或標(biāo)的物簽署一份協(xié)議，來明確地約定各自對此的權(quán)利和義務(wù)，舉個例子來說，甲要買一個機(jī)器，乙負(fù)責(zé)供應(yīng)機(jī)器，丙負(fù)責(zé)在現(xiàn)場安裝機(jī)器，就可以簽一份三方協(xié)議來約定各自的任務(wù)、權(quán)利、義務(wù)、付款、責(zé)任等。我個人不喜歡簽三方協(xié)議，所以一般我會建議項目組盡可能兩方簽，原因一是三方的權(quán)利義務(wù)混在一起，不容易寫清楚；二是除非寫得很直白，絕不為第三方擔(dān)責(zé)，否則有連帶責(zé)任之嫌，這樣如果合同執(zhí)行的過程中出了問題，三方攪在一起，不容易說清楚各自的責(zé)任承擔(dān)；三是談判過程可能拖得時間比較長，因為三方的觀點不盡相同，一份合同條款要讓三方都能接受更不容易。