GET和POST的區(qū)別？

GET和POST方法沒有實(shí)質(zhì)上區(qū)別，只是報(bào)文格式不同。GET和POST是HTTP協(xié)議中的兩種請(qǐng)求方法。而 HTTP 協(xié)議是基于 TCP/IP 的應(yīng)用層協(xié)議，無論 GET 還是 POST，用的都是同一個(gè)傳輸層協(xié)議，所以在傳輸上，沒有區(qū)別。

(1)GET請(qǐng)求的參數(shù)是放在URL里的，POST請(qǐng)求參數(shù)是放在請(qǐng)求body里的。因此：

POST方法比GET方法安全，因?yàn)閿?shù)據(jù)在地址欄不可見。

GET方法有長(zhǎng)度限制，POST方法沒有。HTTP協(xié)議沒有Body和URL的長(zhǎng)度限制，對(duì)URL限制大多數(shù)瀏覽器和服務(wù)器的原因。(大多數(shù)瀏覽器限制url長(zhǎng)度在2k個(gè)字節(jié)，服務(wù)器最多處理64k字節(jié)的url)

GET請(qǐng)求的參數(shù)只能是ASCII碼，所以中文需要URL編碼，POST支持多種編碼方法。

(2)GET方法是冪等方法，對(duì)資源做查詢多次，此實(shí)現(xiàn)的結(jié)果都是一樣的。POST是非冪等方法，因?yàn)橐淮握?qǐng)求添加一份新資源，二次請(qǐng)求則添加了兩份新資源，多次請(qǐng)求會(huì)產(chǎn)生不同的結(jié)果，因此POST不是冪等操作。

PUT和POST方法的區(qū)別？

冪等性不同。PUT請(qǐng)求是冪等性方法，將A修改為B，它第一次請(qǐng)求值變?yōu)榱薆，再進(jìn)行多次此操作，最終的結(jié)果還是B，與一次執(zhí)行的結(jié)果是一樣的，所以PUT是冪等操作。

HTTP1.1和HTTP1.0區(qū)別？

HTTP 1.0默認(rèn)支持短連接。瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過去的請(qǐng)求。

這也造成了一些性能上的缺陷，例如，一個(gè)包含有許多圖像的網(wǎng)頁文件中并沒有包含真正的圖像數(shù)據(jù)內(nèi)容，而只是指明了這些圖像的URL地址，當(dāng)WEB瀏覽器訪問這個(gè)網(wǎng)頁文件時(shí)，瀏覽器首先要發(fā)出針對(duì)該網(wǎng)頁文件的請(qǐng)求，當(dāng)瀏覽器解析WEB服務(wù)器返回的該網(wǎng)頁文檔中的HTML內(nèi)容時(shí)，發(fā)現(xiàn)其中的img圖像標(biāo)簽后，瀏覽器將根據(jù)img標(biāo)簽中的src屬性所指定的URL地址再次向服務(wù)器發(fā)出下載圖像數(shù)據(jù)的請(qǐng)求。

**HTTP 1.1支持持久連接，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。**一個(gè)包含有許多圖像的網(wǎng)頁文件的多個(gè)請(qǐng)求和應(yīng)答可以在一個(gè)連接中傳輸，但每個(gè)單獨(dú)的網(wǎng)頁文件的請(qǐng)求和應(yīng)答仍然需要使用各自的連接。

HTTP 1.1還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求，但服務(wù)器端必須按照接收到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過程所需要的時(shí)間。

TCP擁塞控制方法？

慢開始、擁塞避免、快重傳、快恢復(fù)。

TCP和UDP區(qū)別？

(1)TCP面向連接，UDP面向無連接。

(2)TCP提供可靠的服務(wù)，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá)。UDP不保證可靠交付。

(3)TCP對(duì)系統(tǒng)資源要求較多，UDP對(duì)系統(tǒng)資源要求較少。

(4)每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信。

(5)UDP具有較好的實(shí)時(shí)性，工作效率比TCP高，適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。

(6)TCP首部開銷較大，20個(gè)字節(jié)；UDP首部開銷較小，8個(gè)字節(jié)。

TCP和UDP編程步驟

TCP:

TCP編程的服務(wù)器端一般步驟是：

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()；

2、設(shè)置socket屬性，用函數(shù)setsockopt(); * 可選

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();

4、開啟監(jiān)聽，用函數(shù)listen()；

5、接收客戶端上來的連接，用函數(shù)accept()；

6、收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或者read()和write();

7、關(guān)閉網(wǎng)絡(luò)連接；

8、關(guān)閉監(jiān)聽；

TCP編程的客戶端一般步驟是：

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()；

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();* 可選

4、設(shè)置要連接的對(duì)方的IP地址和端口等屬性；

5、連接服務(wù)器，用函數(shù)connect()；

6、收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或者read()和write();

7、關(guān)閉網(wǎng)絡(luò)連接；

UDP:

與之對(duì)應(yīng)的UDP編程步驟要簡(jiǎn)單許多，分別如下：

UDP編程的服務(wù)器端一般步驟是：

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()；

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();

4、循環(huán)接收數(shù)據(jù)，用函數(shù)recvfrom();

5、關(guān)閉網(wǎng)絡(luò)連接；

UDP編程的客戶端一般步驟是：

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()；

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();* 可選

4、設(shè)置對(duì)方的IP地址和端口等屬性;

5、發(fā)送數(shù)據(jù)，用函數(shù)sendto();

6、關(guān)閉網(wǎng)絡(luò)連接；

UDP應(yīng)用場(chǎng)景

(1)面向數(shù)據(jù)包方式。

(2)數(shù)據(jù)多為短消息。

(3)擁有大量Client。

(4)對(duì)安全性無特殊要求。

(5)網(wǎng)絡(luò)負(fù)擔(dān)重，對(duì)響應(yīng)速度要求高。

UDP實(shí)現(xiàn)可靠傳輸

UDP是面向無連接的協(xié)議，擁有資源消耗少，處理數(shù)據(jù)快的優(yōu)點(diǎn)。所以音頻、視頻和普通數(shù)據(jù)在傳送時(shí)，使用UDP較多。

傳輸層無法保證數(shù)據(jù)的可靠傳輸，可以在應(yīng)用層模仿TCP的可靠性傳輸。

(1)添加seq/ack機(jī)制。

(2)添加發(fā)送和接受緩沖區(qū)，主要為用戶超時(shí)重傳。

(3)添加超時(shí)重傳機(jī)制。

實(shí)現(xiàn)了udp可靠傳輸?shù)拈_源程序：

(1)RUDP

RUDP 提供一組數(shù)據(jù)服務(wù)質(zhì)量增強(qiáng)機(jī)制，如擁塞控制的改進(jìn)、重發(fā)機(jī)制及淡化服務(wù)器算法等，從而在包丟失和網(wǎng)絡(luò)擁塞的情況下， RTP 客戶機(jī)(實(shí)時(shí)位置)面前呈現(xiàn)的就是一個(gè)高質(zhì)量的 RTP 流。在不干擾協(xié)議的實(shí)時(shí)特性的同時(shí)，可靠 UDP 的擁塞控制機(jī)制允許 TCP 方式下的流控制行為。

(2)RTP

RTP為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對(duì)端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。

應(yīng)用程序通常在 UDP 上運(yùn)行 RTP 以便使用其多路結(jié)點(diǎn)和校驗(yàn)服務(wù)；這兩種協(xié)議都提供了傳輸層協(xié)議的功能。但是 RTP 可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議一起使用。如果底層網(wǎng)絡(luò)提供組播方式，那么 RTP 可以使用該組播表傳輸數(shù)據(jù)到多個(gè)目的地。

RTP 本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量(QoS)保證，它依賴于底層服務(wù)去實(shí)現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實(shí)行有序傳送， RTP 中的序列號(hào)允許接收方重組發(fā)送方的包序列，同時(shí)序列號(hào)也能用于決定適當(dāng)?shù)陌恢?#xff0c;例如：在視頻解碼中，就不需要順序解碼。

(3)UDT

基于UDP的數(shù)據(jù)傳輸協(xié)議(UDP-basedData Transfer Protocol，簡(jiǎn)稱UDT)是一種互聯(lián)網(wǎng)數(shù)據(jù)傳輸協(xié)議。UDT的主要目的是支持高速廣域網(wǎng)上的海量數(shù)據(jù)傳輸，而互聯(lián)網(wǎng)上的標(biāo)準(zhǔn)數(shù)據(jù)傳輸協(xié)議TCP在高帶寬長(zhǎng)距離網(wǎng)絡(luò)上性能很差。

顧名思義，UDT建于UDP之上，并引入新的擁塞控制和數(shù)據(jù)可靠性控制機(jī)制。UDT是面向連接的雙向的應(yīng)用層協(xié)議。它同時(shí)支持可靠的數(shù)據(jù)流傳輸和部分可靠的數(shù)據(jù)報(bào)傳輸。由于UDT完全在UDP上實(shí)現(xiàn)，它也可以應(yīng)用在除了高速數(shù)據(jù)傳輸之外的其它應(yīng)用領(lǐng)域，例如點(diǎn)到點(diǎn)技術(shù)(P2P)，防火墻穿透，多媒體數(shù)據(jù)傳輸?shù)鹊取?/p>

負(fù)載均衡

將服務(wù)器部署多臺(tái)，然后通過負(fù)載均衡將用戶的請(qǐng)求發(fā)送到不同的服務(wù)器來提高服務(wù)的性能以及可靠性。

負(fù)載均衡算法：

(1)隨機(jī)算法

按權(quán)重設(shè)置隨機(jī)概率。在一個(gè)截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重。

(2)輪詢以及加權(quán)輪詢

輪詢(Round Robbin)當(dāng)服務(wù)器群中各服務(wù)器的處理能力相同時(shí)，且每筆業(yè)務(wù)處理量差異不大時(shí)，最適合使用這種算法。 輪循，按公約后的權(quán)重設(shè)置輪循比率。存在慢的提供者累積請(qǐng)求問題，比如：第二臺(tái)機(jī)器很慢，但沒掛，當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那，久而久之，所有請(qǐng)求都卡在調(diào)到第二臺(tái)上。

加權(quán)輪詢(Weighted Round Robbin)為輪詢中的每臺(tái)服務(wù)器附加一定權(quán)重的算法。比如服務(wù)器1權(quán)重1，服務(wù)器2權(quán)重2，服務(wù)器3權(quán)重3，則順序?yàn)?-2-2-3-3-3-1-2-2-3-3-3- …

(3)最小連接以及加權(quán)最小連接

最少連接(Least Connections)在多個(gè)服務(wù)器中，與處理連接數(shù)(會(huì)話數(shù))最少的服務(wù)器進(jìn)行通信的算法。即使在每臺(tái)服務(wù)器處理能力各不相同，每筆業(yè)務(wù)處理量也不相同的情況下，也能夠在一定程度上降低服務(wù)器的負(fù)載。

加權(quán)最少連接(Weighted Least Connection)為最少連接算法中的每臺(tái)服務(wù)器附加權(quán)重的算法，該算法事先為每臺(tái)服務(wù)器分配處理連接的數(shù)量，并將客戶端請(qǐng)求轉(zhuǎn)至連接數(shù)最少的服務(wù)器上。

(4)哈希算法

普通哈希

一致性哈希一致性Hash，相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者。當(dāng)某一臺(tái)提供者掛時(shí)，原本發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其它提供者，不會(huì)引起劇烈變動(dòng)。

(5)IP地址散列

通過管理發(fā)送方IP和目的地IP地址的散列，將來自同一發(fā)送方的分組(或發(fā)送至同一目的地的分組)統(tǒng)一轉(zhuǎn)發(fā)到相同服務(wù)器的算法。當(dāng)客戶端有一系列業(yè)務(wù)需要處理而必須和一個(gè)服務(wù)器反復(fù)通信時(shí)，該算法能夠以流(會(huì)話)為單位，保證來自相同客戶端的通信能夠一直在同一服務(wù)器中進(jìn)行處理。

(6)URL散列

通過管理客戶端請(qǐng)求URL信息的散列，將發(fā)送至相同URL的請(qǐng)求轉(zhuǎn)發(fā)至同一服務(wù)器的算法。

OSI七層模型的每一層都有哪些協(xié)議

物理層：EIA/TIA-232, EIA/TIA-499, V.35, V.24, RJ45, Ethernet, 802.3, 802.5, FDDI, NRZI, NRZ, B8ZS

數(shù)據(jù)鏈路層：Frame Relay, HDLC, PPP, IEEE 802.3/802.2, FDDI, ATM, IEEE 802.5/802.2

網(wǎng)絡(luò)層：IP，IPX，AppleTalk DDP

傳輸層：TCP，UDP，SPX

會(huì)話層：RPC,SQL,NFS,NetBIOS,names,AppleTalk,ASP,DECnet,SCP

表示層:TIFF,GIF,JPEG,PICT,ASCII,EBCDIC,encryption,MPEG,MIDI,HTML

應(yīng)用層：FTP,WWW,Telnet,NFS,SMTP,Gateway,SNMP

TCP/IP用到了那些協(xié)議，在哪一層

數(shù)據(jù)鏈路層：ARP,RARP

網(wǎng)絡(luò)層： IP,ICMP,IGMP

傳輸層：TCP ,UDP,UGP

應(yīng)用層：Telnet,FTP,SMTP,SNMP.

總結(jié)

以上是生活随笔為你收集整理的计算机网络英文面试题,计算机网络面试题整理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。