image.png

Xml與JSON區(qū)別

數(shù)據(jù)交換格式

• 區(qū)別:
  xml是重量級、json是輕量級
  xml占帶寬大，不易壓縮、json占帶寬小,易于壓縮
  在webservice：xml用的較多、json用的比較少
  相同：
  兩者都用在項目交互下 例如 移動app接口用的就是json、在web項目中與其他項目對接用xml較多。
• json常用解析方法 gson、jsonobject、jackson等
• xml常用解析方法 dom sax pull

TCP與UDP區(qū)別？ 聊天、網(wǎng)絡(luò)視頻會議、桌面共享用的就是 UDP

UDP:
a、是面向無連接, 將數(shù)據(jù)及源的封裝成數(shù)據(jù)包中,不需要建立建立連接
b、每個數(shù)據(jù)報的大小在限制64k內(nèi)
c、因無連接,是不可靠協(xié)議
d、不需要建立連接,速度快
TCP：
a、建議連接，形成傳輸數(shù)據(jù)的通道.
b、在連接中進行大數(shù)據(jù)量傳輸，以字節(jié)流方式
c、通過三次握手完成連接,是可靠協(xié)議
d、必須建立連接，效率會稍低

說說三次握手?

1）第一次握手：建立連接時，客戶端A發(fā)送SYN包（SYN=j）到服務(wù)器B，并進入SYN_SEND狀態(tài)，等待服務(wù)器B確認(rèn)。
（2）第二次握手：服務(wù)器B收到SYN包，必須確認(rèn)客戶A的SYN（ACK=j+1），同時自己也發(fā)送一個SYN包（SYN=k），即SYN+ACK包，此時服務(wù)器B進入SYN_RECV狀態(tài)。
（3）第三次握手：客戶端A收到服務(wù)器B的SYN＋ACK包，向服務(wù)器B發(fā)送確認(rèn)包ACK（ACK=k+1），此包發(fā)送完畢，客戶端A和服務(wù)器B進入ESTABLISHED狀態(tài)，完成三次握手。
完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。

什么是Webserivce?

Webservice：提供不同的平臺相互通訊，基于Soap協(xié)議。
Web service 就是一個應(yīng)用程序，它向外界暴露出一個能夠通過Web進行調(diào)用的API。
SOAP是基于xml的輕量協(xié)議，soap請求是HTTP POST的一個專用版本，遵循一種特殊的xml消息格式Content-type設(shè)置為: text/xml。

WebService實現(xiàn)原理是？

HTTP協(xié)議+XML

說一下什么是Http協(xié)議？

對客戶端和服務(wù)器端之間數(shù)據(jù)傳輸?shù)母袷揭?guī)范，格式簡稱為“超文本傳輸協(xié)議”。

什么是Http協(xié)議無狀態(tài)協(xié)議？

無狀態(tài)協(xié)議對于事務(wù)處理沒有記憶能力。

怎么解決Http協(xié)議無狀態(tài)協(xié)議？

無狀態(tài)協(xié)議解決辦法： 通過1、Cookie 2、通過Session會話保存。

Http協(xié)議有什么組成？

請求報文包含三部分：
a、請求行：包含請求方法、URI、HTTP版本信息
b、請求首部字段
c、請求內(nèi)容實體
響應(yīng)報文包含三部分：
a、狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語
b、響應(yīng)首部字段
c、響應(yīng)內(nèi)容實體

Http協(xié)議中有那些請求方式？

GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標(biāo)識符）識別的資源，可以通過URL傳參給服務(wù)器
POST：用于傳輸信息給服務(wù)器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT： 傳輸文件，報文主體中包含文件內(nèi)容，保存到對應(yīng)URI位置。
HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應(yīng)URI位置的文件。

Http協(xié)議實現(xiàn)原理機制？
2.1、整個流程步驟

image.png

2.2、域名解析過程

image.png

2.6、瀏覽器解析HTML代碼
2.7、瀏覽器對頁面進行渲染呈現(xiàn)給用戶

get與post請求區(qū)別？（初級程序員必備問題）

• get重點在從服務(wù)器上獲取資源，post重點在向服務(wù)器發(fā)送數(shù)據(jù)；
• get傳輸數(shù)據(jù)是通過URL請求，以field（字段）= value的形式，置于URL后，并用"?"連接，多個請求數(shù)據(jù)間用"&"連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；
  post傳輸數(shù)據(jù)通過Http的post機制，將字段與對應(yīng)值封存在請求實體中發(fā)送給服務(wù)器，這個過程對用戶是不可見的；
• Get傳輸?shù)臄?shù)據(jù)量小，但效率較高；
  Post可以傳輸大量數(shù)據(jù)，所以上傳文件時只能用Post方式；
• get是不安全的，因為URL是可見的，可能會泄露私密信息，如密碼等；
  post較get安全性較高；
• get方式只能支持ASCII字符，向服務(wù)器傳的中文字符可能會亂碼。
  post支持標(biāo)準(zhǔn)字符集，可以正確傳遞中文字符。

Http請求報文與響應(yīng)報文格式？

請求報文包含三部分：
a、請求行：包含請求方法、URI、HTTP版本信息
b、請求首部字段
c、請求內(nèi)容實體
響應(yīng)報文包含三部分：
a、狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語
b、響應(yīng)首部字段
c、響應(yīng)內(nèi)容實體

10、常見Http協(xié)議狀態(tài)？

200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務(wù)器只對請求的部分資源執(zhí)行GET方法，相應(yīng)報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務(wù)器無法識別
401：請求需要認(rèn)證
403：請求的對應(yīng)資源禁止被訪問
404：服務(wù)器無法找到對應(yīng)資源
500：服務(wù)器內(nèi)部錯誤
503：服務(wù)器正忙

Http協(xié)議首部字段？

a、通用首部字段（請求報文與響應(yīng)報文都會使用的首部字段）
Date：創(chuàng)建報文時間
Connection：連接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式
b、請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務(wù)器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內(nèi)容編碼
Accept-Language：可接受的自然語言
c、響應(yīng)首部字段（響應(yīng)報文會使用的首部字段）
Accept-Ranges：可接受的字節(jié)范圍
Location：令客戶端重新定向到的URI
Server：HTTP服務(wù)器的安裝信息
d、實體首部字段（請求報文與響應(yīng)報文的的實體部分使用的首部字段）
Allow：資源可支持的HTTP方法
Content-Type：實體主類的類型
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的自然語言
Content-Length：實體主體的的字節(jié)數(shù)
Content-Range：實體主體的位置范圍，一般用于發(fā)出部分請求時使用

Http與Https優(yōu)缺點？

a、通信使用明文不加密，內(nèi)容可能被竊聽，也就是被抓包分析。
b、不驗證通信方身份，可能遭到偽裝
c、無法驗證報文完整性，可能被篡改
HTTPS就是HTTP加上加密處理（一般是SSL安全通信線路）+認(rèn)證+完整性保護

Http優(yōu)化

利用負(fù)載均衡優(yōu)化和加速HTTP應(yīng)用
利用HTTP Cache來優(yōu)化網(wǎng)站

Http協(xié)議有那些特征？

1、支持客戶/服務(wù)器模式；2、簡單快速；3、靈活；4、無連接；5、無狀態(tài)；