TCP/IP、HTTP面試題及解

Question：

　　OSI/RM（Open System Interconnection Reference Model）開放系統互連參考模型分幾層？

Answer：

　　分爲7層，自下到上分別是：物理層、數據鏈路層、網絡層、運輸層、會話層、表示層、應用層。

 

Question：

　　TCP/IP體系結構分爲幾層？

Answer：

　　分別4層，自下到上分別是：網絡接口層、網絡層、運輸層、應用層。

 

Question：

　　詳細描述TCP三次握手的過程

Answer：

　　過程以下圖

　　

 

Question：

　　爲何發起請求方在收到接收方的接受請求確認後，還要發送一個報文？

Answer：

　　爲了防止已失效的鏈接請求報文又忽然出現，而且傳給了B，致使又創建一次鏈接。試想這樣一個情景：TCP鏈接只有2次握手，那麼，A發起請求後，B發回響應後，就創建鏈接了，可是呢，A發起了兩個鏈接請求報文，第一次報文發送以後，在網絡中「迷路了」，並無到達B，因此A在一段時間內沒有收到B的響應，因此A又發起了一個鏈接請求報文，而後呢，這個報文到達了B，而且A收到了B發來的鏈接確認，那麼此時A和B的鏈接就創建了。傳輸完數據，釋放連接以後，剛剛A發送的那個「迷路」的請求鏈接報文神奇地到達了B，此時B給A發送一個鏈接確認，那麼A在接收到確認報文後，A和B之間又創建了一次鏈接，然而，A此時並無要和B創建鏈接的想法，是否是出問題了呢？此時，就能夠看出來，A對於B的鏈接確認報文必需要再發送一個確認，以防出現半打開的狀況。

 

Question：

　　若是服務器不想和客戶端創建鏈接怎麼辦？

Answer：

　　在返回的報文中，不要將SYN置爲1，而是將RST置爲1便可。

 

Question

　　假設服務器的80端口沒有打開，那麼客戶端請求服務器的80端口，想要創建鏈接，請問服務器會發迴響應嗎？

Answer

　　會發迴響應，不會創建鏈接，因此會將RST置爲1。

　　這樣可能會受到DDoS攻擊（SYN-Flood攻擊）

 

Question：

　　若是短期出現大量鏈接請求的攻擊，這種方式稱做什麼攻擊？怎麼解決？

Answer：

　　SYN flood攻擊，屬於DDoS攻擊，解決方案能夠參考博客：http://www.cnblogs.com/hubavyn/p/4477883.html

 

Question：詳細描述TCP釋放鏈接的過程

Answer：

　　

 

Question：

　　在服務器返回給客戶端斷開鏈接的確認後，此時處於什麼狀態？

Answer：

　　半關閉狀態

 

Question：

　　在服務器返回給客戶端斷開鏈接的確認後，若是服務器還有數據要發給客戶端，客戶端還會接收數據嗎？

Answer：

　　仍舊會接收數據

 

Question：

　　爲何A在Time-Wait狀態時，要等待2MSL的時間？

Answer：

　　爲了保證 A 發送的最後一個 ACK 報文段可以到達 B，爲何是2MSL，由於，若是在MSL內，A發送的最後一個ACK報文沒有到達B，那麼B就會再次發起斷開鏈接請求，該報文又是一個MSL，因此是MSL，若是在2MSL中，A都沒有再次收到斷開鏈接的請求報文，那麼就證實B收到了最後一個ACK確認，TCP鏈接才能夠真正斷開。

 

Question：

　　標誌字段中，FIN和RST分別在何時使用？

Answer：

　　FIN是在正常斷開鏈接的時候使用；RST是在異常斷開鏈接的時候使用，好比服務器宕機了。

 

Question：HTTP協議中，有哪些請求方法？含義是什麼？

Answer：

方法名	含義	在REST中的含義
GET	獲取資源	獲取資源
POST	傳輸實體主題（提交數據）	建立一個新資源
PUT	傳輸文件	更新一個已有的資源
DELETE	刪除文件	刪除一個資源
HEAD	獲取報文首部（不須要返回實體首部）	獲取報文首部（不須要返回實體首部）
OPTIONS	詢問支持的方法	詢問支持的方法
TRACE	追蹤路徑
CONNECT	要求使用隧道協議鏈接代理

 

 

Question：

　　HTTP協議的狀態碼？分別在哪些狀況下返回哪一個狀態碼？

Answer：

　　摘抄自https://httpstatuses.com/    能夠查看本文末尾，有較完整的狀態碼

狀態碼	含義
200（OK）	請求被服務器正常處理
204（No Content）	請求被正常處理，可是響應報文中不包含實體主體
206（Partial Content）	返回客戶端請求的部分數據
301（Moved Permanently）	永久重定向（SEO評分會轉移到重定向的網址）
302（Found）	臨時重定向（通常短地址會返回這個狀態碼）
304（Not Modified）	服務器端的資源未改變，可直接使用緩存中的資源
400（Bad Request）	客戶端請求報文中傳輸的數據格式錯誤，服務器沒法解析
401（Unauthoried）	表示客戶端沒有通過受權認證，沒法訪問
403（Forbidden）	服務器端拒絕客戶端訪問該資源，沒有權限或者權限不夠
404（Not Found）	表示客戶端請求的資源在服務器上未找到
500（Internal Server Error）	服務器遇到某種事故，致使服務器崩潰了
502（Bad Gateway）	做爲網關或者代理工做的服務器嘗處理請求時，沒有上游服務器進程處理請求，或者解析腳本的時候後端程序有錯誤（最簡單的缺個分號）。
503（Service Unavailable）	服務器接受的請求太多（超負荷），致使請求得不處處理
504（Gateway Timeout）	做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器得到響應

 

 

Question：

　　http協議中狀態碼500、50二、50三、504的區別

Answer：

　　背景：一、nginx做服務器；二、使用php-fpm

　　500：nginx服務器負載太高，直接崩潰了。

　　502：nginx將解析php的請求轉發給php-fpm後，若是php-fpm的沒有可用的worker（處理進程），沒有足夠的php-fpm的worker去處理請求，或者說php-fpm解析php腳本時，發現腳本有錯誤（缺一個分號），都會返回502狀態碼。

　　503：nginx服務器最多一次性能夠接受1萬個請求，若是此時瞬間有10萬個請求到達，即便是反向代理轉發，nginx也忙不過來，致使一些請求得不處處理，此時就會返回503狀態碼。

　　504：nginx將請求轉發給php-fpm以後，未能及時得到php-fpm的響應，就會返回504狀態碼。

 

Question：

　　https怎麼保證傳輸安全？

Answer：

　　一、證書；二、各類加密（RSA）

 

Question：常見的應用層協議使用的端口

Answer：

應用層協議	默認端口	使用的下層協議（傳輸層）
FTP	21	TCP
TFTP	69	UDP
SSH	22	TCP
DNS	53	UDP
HTTP	80	TCP
HTTPS	443	TCP
SMTP	161	TCP
DHCP	67（發送）--- 68（接收）	UDP
TELNET	23	TCP
REDIS	6379	TCP
MySQL	3306	TCP
Memcache	11211	TCP

 

 

Question：

　　介紹一下http緩存？

Answer：

　　http緩存使用在瀏覽器-服務器架構下，瀏覽器在發起請求後，服務器在返回響應的中設置http緩存相關頭部信息以後，瀏覽器在接收到數據以後，會按照頭部信息的要求，對某些資源進行緩存，下一次，瀏覽器再次對某一個資源的訪問，若是緩存中存在，而且沒有過時，那麼就直接從緩存中獲取，不用再向服務器請求一次該資源，有效地減小服務器的壓力。

 

Question：http緩存的三種模型？

Answer：

　　首先get請求能夠被緩存，可是post請求不能被緩存。要想使用http緩存，是經過響應中的頭部字段決定的，好比：Pragma、Expires、Cache-Control、Last-Modified、Etag。

　　一、200 OK（from memory cache）：直接從本地緩存中獲取相應，最快速，最省流量的請求方式，不會發起請求。

　　二、304 Not Modified：協商緩存，瀏覽器在本地緩存失效的狀況下，詢問服務器，該資源內容是否發生改變，若是服務器端數據沒有改變的話，就返回給瀏覽器304狀態碼，只返會一些基本的響應頭信息，不返回響應體。這裏涉及到兩個概念，Last--Modified-Since、Last-Modified、Etag.

　　三、200 OK：以上兩種緩存都失敗了，服務器就會返回完整響應，沒有用到緩存，速度相對較慢。

 

Question：

　　本地緩存機制以及header？

Answer：

　　一、本地緩存：瀏覽器認爲本地緩存可使用，不會去請求服務器端。

　　二、Pragma：HTTP 1.0，該字段通常被設置爲no-cache是，會告知瀏覽器禁用本地緩存，即每次都向服務器發送請求。

　　三、Expires：HTTP 1.0，用來啓用本地緩存，值是一個格林威治時間，告訴瀏覽器緩存失效的時刻，超過該時間，緩存就會失效；若是還沒到達該時刻，代表緩存仍舊有效，無需發送請求。存在的問題：響應的時間戳是格林威治時間（全球通用的），可是，這個時間是服務器端設置的，服務器能夠保證時間偏差在必定範圍內，可是客戶端瀏覽器由於地理位置的不一樣、時區的差別，若是時間差距大的話，就會影響緩存結果。

　　四、Cache-Control：HTTP 1.1，告知瀏覽器緩存過時時間的間隔，而不是時刻。因此瀏覽器在收到響應以後的一段時間內有效，即便時區不一樣，具體的時間不一致，也不影響緩存管理。Cache-Control能夠設置爲一下值：

　　　　a、no-store：禁止瀏覽器緩存響應。

　　　　b、no-cache：不容許直接使用本地緩存，要先發起請求和服務器協商，看緩存的資源是否發送改變。

　　　　c、max-age=有效期：告知瀏覽器該響應本地緩存的有效期是多長，單位是秒。

　　優先級：Pragma > Cache-Control > Expires

　　五、Etag：HTTP1.1，文件的指紋標識符，若是文件內容發生了修改，指紋也會發生改變。

 

Question：

　　介紹協商緩存的過程？

Answer：

　　當瀏覽器當前的緩存過時了，或者說Cache-Control中設置爲no-cache聲明不容許直接使用緩存，那麼瀏覽器就必須先發起請求。這裏有兩種狀況：

　　一、請求的資源最後一次文件修改時間發生改變，內容發生了改變。

　　二、請求的資源最後一次文件修改時間發生改變，內容沒有發生改變。

　　第一次請求服務器中的某個資源時，若是服務器須要使用協商緩存，那麼就會在響應中，就會將Cache-Control字段設爲no-cache，同時也會返回一個Last-Modified字段標誌該資源最後一次更新的時間，客戶端瀏覽器收到響應以後，會將響應緩存起來，下次須要使用該資源時，會首先請求服務器，請求頭中有一個If-Modified-Since字段，值爲上一次服務器端返回響應中的Last-Modified值。服務器收到該字段後，會首先查看服務器端的該資源的最後一次修改文件的時間是否發生了改變，若是發生了改變，就將資源從新發回客戶端；若是最後修改時間沒有修改時間，那就返回304狀態碼。

　　可是存在這樣一個場景，上面請求的那個資源，雖然最後一次修改的時間發生了改變，可是，內容沒有變。有這種狀況，程序員增長了一行代碼，保存以後，發現有問題，因而又把那一行代碼刪了，因而乎，資源最後一次修改時間發生了改變，內容卻沒有改變。 此時，可使用Etag頭部字段，這個字段就是與資源的內容有關的，能夠理解爲資源的摘要。服務器端在響應中會發送Etag，以後瀏覽器在請求的時候會攜帶着這個Etag（If-None-Match），服務器端接收到If-Modified-Since字段和If-None-Match字段後，若是發現最後一次修改的時間沒變，那麼就直接返回304；若是時間發生了改變，那再看內容摘要是否發生了改變，若是內容摘要沒發生變化，照樣發回304，不然返回資源。

　　可使用下面的代碼理解：

check() { 
	//第一次請求，直接返回內容，以及Last-Modified、Etag
	if (first.Request) { 
		return array( 
			"Cache-Control" => "no-cache",
			"Last-Modified" => filemtime("demo.txt"),
			"Etag" 			=> md5(file_get_content("demo.txt")),
			"content" 		=> file_get_content("demo.txt")
		)
	}

	//非第一次請求
	if (Request.If-Modefied-Since == filemtime(file_get_content("demo.txt"))) {
		return 304;
	} else {
		if (Request.If-None-Match == md5(file_get_content("demo.txt"))) {
			return 304;
		} else {
			return array( 
				"Cache-Control" => "no-cache",
				"Last-Modified" => filemtime("demo.txt"),
				"Etag" 			=> md5(file_get_content("demo.txt")),
				"content" 		=> file_get_content("demo.txt")
			)
		}
	}
}

　　

　　

Question：哪些文件適合作本地緩存？

Answer：不變的圖片（logo、圖標）；js、css靜態文件；可下載的內容、媒體文件。

 

Question：哪些文件使用協商緩存？

Answer：HTML文件、常常替換的圖片、常常修改的js、css文件。

 

Question： css和js怎麼實現不緩存？

Answer：除了上面的Etag、Last-Modified，還能夠在末尾加一個隨機數（index.css?v=xxxx）

 

Question：不建議緩存的內容？

Answer：一、用戶隱私數據； 二、API接口返回的結果

 

Question：Nginx怎麼設置緩存？

Answer：

　　一、設置expires值，30d表示30天內有效，12h表示12個小時有效；max表示10年過時。

　　二、etag設置爲on便可，值爲off時，表示關閉etag。

　　三、add_header cache-control max-age=3600

 

Question

　　一個項目完成升級後，QA在測試的時候，發現網站內容沒有改變，這是由於有緩存的緣故，由於緩存沒有過時，就會使用已經緩存的內容。這算事故（bug）嗎？

Answer

　　首先，這確定算是事故（bug），好比，一個網站，發佈新版本後，用戶訪問的時候，發現根本就沒發生改變，由於使用的是緩存的css或者js，開發人員不可能打電話通知用戶進行強制刷新（Ctrl + F5），這是不現實的。

　　解決方案能夠按照前面實現不緩存的方法，在js或者css後面增長一個版本號，demo.js?version=VarName，這一這個varname可使用時間戳，但建議的是使用版本號，每發佈一個版本就更改一下版本號，便可解決以前的問題。

 

Question：

　　常見的http協議請求頭部信息的含義？

Answer：

出如今什麼報文中	頭部信息	含義	示例值
請求	Accept	客戶端（客戶）可以處理的響應內容的類型	text/html
	Accept-Charset	優先使用的字符集	iso-8859-5
	Accept-Encoding	優先使用的編碼格式	gzip, deflate
	Accept-Language	優先使用的語言	zh-cn
	Authorization	Web認證信息
	Host	請求資源所在服務器	www.cnblogs.com
	Range	但願服務器返回的字節範圍	bytes=5000-10000
	User-Agent	Http客戶端的信息	chrom、postman、mozilla
	Max-Forwrads	最大傳輸跳數（代理）	10
	Referer	對某個URL發起請求的原始獲取方（盜鏈、防盜鏈）	www.cnblogs.com
	Origin	請求方的源	www.baidu.com
請求-響應	Pragma	告知客戶端是否緩存響應的內容	no-cache
響應	Expires	告知客戶端緩存返回的資源，在該時刻（格林威治時間）以前有效	Tue, 24 Aug 2038 18:26:15 GMT
請求-響應	Cache-Control	告知客戶端怎麼使用返回的響應，緩存、不緩存、有效期	no-store、no-cache、max-age=123
響應	Last-Modified	返回的資源最後修改時間（格林威治時間）	Wed, 29 Aug 2018 18:26:15 GMT
響應	Etag	服務器端在返回資源的同時，也返回改header，表示資源的指紋
請求	Last-Modified-Since	客戶端在發起請求時，攜帶以前服務器端返回的Last-Modified值。
請求	Last-None-Match	客戶端在發起請求時，攜帶以前服務器端返回的Etag值
響應	Age	代理服務器發給客戶端，告知客戶端源服務器在多久以前建立了該資源。	600(10分鐘）
響應	Date	資源建立的時間	Fri, 31 Aug 2018 02:55:36 GMT
響應	Server	告知客戶端：服務器使用什麼http應用程序	apache/2.2.2
響應	Location	重定向	www.cnblogs.com
請求-響應	Upgrade	升級爲其餘協議	websocket
請求-響應	Connection	刪除首部或者管理持久鏈接
響應	Allow	資源可支持的http方法（對options的響應）	GET、POST
	Content-Type	實體主體的類型
	Content-Length	實體主體的長度
	Content-Range	實體主體的範圍
	Content-Language	實體主體的語言類型

 

 

Question：

　　GET和POST的區別？

Answer：

　　一、get請求時能夠緩存的，post請求不能緩存。

　　二、get的資源能夠添加到書籤，post請求的資源不能添加到書籤。

　　三、get請求不能上傳文件，上傳文件只能使用post請求。

　　四、get請求傳遞的參數會保留在歷史記錄中，post請求的參數不會保留在歷史記錄中和日誌中。

　　五、get請求傳輸的數據有限制，根據客戶端類型有關，通常是2048字節。post請求通常沒有大小限制。

　　六、get請求只能傳輸ASCII碼，post能夠傳遞各類編碼數據。

　　七、get請求傳遞的參數暴露在地址欄上，因此沒有post安全，get傳遞的參數還能夠經過歷史記錄查看到以後。

 

Question：

　　介紹一下https

Answer：

　　https是基於SSL/TLS的HTTP協議，全部的http數據都是在ssl/tls協議封裝之上傳輸的。

　　https協議在http協議的基礎上，添加了SSL/TLS握手以及數據的加密傳輸，也是應用層協議，使用443端口。

　　加密主要是使用rsa公鑰加密算法。

 

 

Question：

　　什麼是盜鏈？怎麼防盜鏈？

Answer：

　　盜鏈就是一個網站使用非本地的資源的行爲，好比，A網站以爲B網站的某張圖片很好看，因而在A站點使用img的src將B站點的圖片連接過來，這就是盜鏈行爲，會加劇B站點服務器的壓力。

　　解決方法：

　　一、使用http協議中的referer字段。

　　　　在nginx中有ngx_http_referer_module用於阻擋來源非法的域名請求。

　　　　配置nginx時，設置valid_referers  none | blocked | server_names | string；

　　　　none：referer頭部爲空時也會被認爲是合法的。

　　　　blocked：referer頭部不爲空，可是裏面的值被代理或者防火牆刪了。

　　　　server_names：本地信任的域名。

location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$ {
    valid_referers none blocked test.com *test.com;
    if ($invalid_referer) {
    	#return 403;
    	rewrite ^/ http://www.test.com/403.png;
    }
}

　　二、使用簽名

　　　　使用第三方模塊HttpAccessKeyModule。

　　　　accesskey on | off   模塊開關

　　　　accesskey_hashmethod md5 | sha-1 簽名加密方式

　　　　accesskey_arg string  設置隨時用get請求時，請求中攜帶的參數。

　　　　accesskey_signature  "demo$remote_addr";    簽名。

location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$ {
    accesskey on;
    accesskey_hashmethod md5;
    accesskey_arg "key";
    accesskey_signature "demo$remote_addr";
}

　　　　工做流程，客戶端請求的時候，攜帶格式爲key=demo192.168.1.1的數據，而後服務器端接收到後，使用md5加密，而後判斷是否合法

 

Question

　　跨域問題的解決方案？

Answer

　　有四種方案，能夠參考：http://www.javashuo.com/article/p-ewqvpdec-gt.html

　　重點講了jsonp，注意一個域由3部分組成（協議、ip或者域名、端口）

 

Question

　　什麼是同源策略？

Answer

　　這裏的源，其實就是域。

　　打開tab_1，訪問一個a.com的資源；再打開一個tab_2，訪問a.com的資源；再打開一個tab_3，訪問b.com的資源。 那麼，tab_1中a.com可使用tab_2中a.com的資源，可是卻不能使用tab_3中的b.com中的資源。好比說js訪問cookie的操做。

　　web瀏覽器容許第一個頁面的腳本訪問第二個頁面裏的數據，可是也只有在兩個頁面有相同的源時。源是由URI，主機名，端口號組合而成的。這個策略能夠阻止一個頁面上的惡意腳本經過頁面的DOM對象得到訪問另外一個頁面上敏感信息的權限。

 

Question

　　介紹一下httponly？

Answer

　　首先看普通狀況，訪問一個頁面的時候，在控制檯中可使用JavaScript來操做cookie，這個實際上是不安全的。

　　那麼，能夠在設置cookie的時候，設置httponly，以後，就不能經過JavaScript來操做cookie了。

 

Question

　　既然https是能夠保證數據的安全，那麼，爲何還要將密碼加密後再傳輸呢？

Answer

　　一、首先，https只是相對於http來講要安全一些，因此他也不是絕對安全的。

　　二、密碼爲甚要加密，首先問一個問題，服務器須要知道用戶的密碼嗎？服務器應該知道用戶的密碼嗎？不須要，也不該該吧。

　　三、若是不加密，就算服務器方不去看用戶密碼，可是，若是服務器被攻擊了，數據泄露了，密碼是否是也泄露了？Yahoo的教訓歷歷在目。

 

Question

　　

Answer

　　

 

 

代碼	消息	描述
100	Continue	只有請求的一部分已經被服務器接收，但只要它沒有被拒絕，客戶端應繼續該請求。
101	Switching Protocols	服務器切換協議。
200	OK	請求成功。
201	Created	該請求是完整的，並建立一個新的資源。
202	Accepted	該請求被接受處理，可是該處理是不完整的。
203	Non-authoritative Information
204	No Content
205	Reset Content
206	Partial Content
300	Multiple Choices	連接列表。用戶能夠選擇一個連接，進入到該位置。最多五個地址。
301	Moved Permanently	所請求的頁面已經轉移到一個新的 URL。
302	Found	所請求的頁面已經臨時轉移到一個新的 URL。
303	See Other	所請求的頁面能夠在另外一個不一樣的 URL 下被找到。
304	Not Modified
305	Use Proxy
306	Unused	在之前的版本中使用該代碼。如今已再也不使用它，但代碼仍被保留。
307	Temporary Redirect	所請求的頁面已經臨時轉移到一個新的 URL。
400	Bad Request	服務器不理解請求。
401	Unauthorized	所請求的頁面須要用戶名和密碼。
402	Payment Required	您還不能使用該代碼。
403	Forbidden	禁止訪問所請求的頁面。
404	Not Found	服務器沒法找到所請求的頁面。.
405	Method Not Allowed	在請求中指定的方法是不容許的。
406	Not Acceptable	服務器只生成一個不被客戶端接受的響應。
407	Proxy Authentication Required	在請求送達以前，您必須使用代理服務器的驗證。
408	Request Timeout	請求須要的時間比服務器可以等待的時間長，超時。
409	Conflict	請求由於衝突沒法完成。
410	Gone	所請求的頁面再也不可用。
411	Length Required	"Content-Length" 未定義。服務器沒法處理客戶端發送的不帶 Content-Length 的請求信息。
412	Precondition Failed	請求中給出的先決條件被服務器評估爲 false。
413	Request Entity Too Large	服務器不接受該請求，由於請求實體過大。
414	Request-url Too Long	服務器不接受該請求，由於 URL 太長。當您轉換一個 "post" 請求爲一個帶有長的查詢信息的 "get" 請求時發生。
415	Unsupported Media Type	服務器不接受該請求，由於媒體類型不被支持。
417	Expectation Failed
500	Internal Server Error	未完成的請求。服務器遇到了一個意外的狀況。
501	Not Implemented	未完成的請求。服務器不支持所需的功能。
502	Bad Gateway	未完成的請求。服務器從上游服務器收到無效響應。
503	Service Unavailable	未完成的請求。服務器暫時超載或死機。
504	Gateway Timeout	網關超時。
505	HTTP Version Not Supported	服務器不支持"HTTP協議"版本。