一.三次握手

1.客戶端通過(guò)向服務(wù)器發(fā)送一個(gè)syn來(lái)創(chuàng)建一個(gè)主動(dòng)打開(kāi)，作為三次握手的一部分,客戶端把這段連接設(shè)定為隨機(jī)數(shù)a
2.服務(wù)器端應(yīng)當(dāng)為一個(gè)合法的SYN回送一個(gè)SYN/ACK。ACK 的確認(rèn)碼應(yīng)為 A+1，SYN/ACK 包本身又有一個(gè)隨機(jī)序號(hào) B。
3.最后，客戶端再發(fā)送一個(gè)ACK。當(dāng)服務(wù)端受到這個(gè)ACK的時(shí)候，就完成了三路握手，并進(jìn)入了連接創(chuàng)建狀態(tài)。此時(shí)包序號(hào)被設(shè)定為收到的確認(rèn)號(hào) A+1，而響應(yīng)則為 B+1。

二.四次揮手

注意: 中斷連接端可以是客戶端，也可以是服務(wù)器端. 下面僅以客戶端斷開(kāi)連接舉例, 反之亦然.
1.客戶端發(fā)送一個(gè)數(shù)據(jù)分段, 其中的 FIN 標(biāo)記設(shè)置為1. 客戶端進(jìn)入 FIN-WAIT 狀態(tài). 該狀態(tài)下客戶端只接收數(shù)據(jù), 不再發(fā)送數(shù)據(jù).
2.服務(wù)器接收到帶有 FIN = 1 的數(shù)據(jù)分段, 發(fā)送帶有 ACK = 1 的剩余數(shù)據(jù)分段, 確認(rèn)收到客戶端發(fā)來(lái)的 FIN 信息.
3.服務(wù)器等到所有數(shù)據(jù)傳輸結(jié)束, 向客戶端發(fā)送一個(gè)帶有 FIN = 1 的數(shù)據(jù)分段, 并進(jìn)入 CLOSE-WAIT 狀態(tài), 等待客戶端發(fā)來(lái)帶有 ACK = 1 的確認(rèn)報(bào)文.
4.客戶端收到服務(wù)器發(fā)來(lái)帶有 FIN = 1 的報(bào)文, 返回 ACK = 1 的報(bào)文確認(rèn), 為了防止服務(wù)器端未收到需要重發(fā), 進(jìn)入 TIME-WAIT 狀態(tài). 服務(wù)器接收到報(bào)文后關(guān)閉連接. 客戶端等待 2MSL 后未收到回復(fù), 則認(rèn)為服務(wù)器成功關(guān)閉, 客戶端關(guān)閉連接.

3.ARP協(xié)議

地址解析協(xié)議（Address Resolution Protocol）其基本功能為透過(guò)目標(biāo)設(shè)備的ip地址，查詢目標(biāo)的mac地址，以保證通信的順利進(jìn)行
它是ipv4網(wǎng)絡(luò)層必不可少的協(xié)議，不過(guò)在ipv6中已經(jīng)不再適用，并被鄰居發(fā)現(xiàn)協(xié)議所替代.

4.urlib和urllib2的區(qū)別

1.urllib提供urlencode方法用來(lái)GET查詢字符串的產(chǎn)生，而urllib2沒(méi)有。這是為何urllib常和urllib2一起使用的原因。
2.urllib2可以接受一個(gè)Request類的實(shí)例來(lái)設(shè)置URL請(qǐng)求的headers，urllib僅可以接受URL。這意味著，你不可以偽裝你的User Agent字符串等。

5.post和get

GET和POST有什么區(qū)別？及為什么網(wǎng)上的多數(shù)答案都是錯(cuò)的 知乎回答
<article class="markdown-body entry-content" itemprop="text">

get: RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 post: RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

6.cookie和session

圖片.png

7.HTTP

http://www.itdecent.cn/p/d398d920f24f

8.apache和nginx區(qū)別

nginx相對(duì)apache的優(yōu)點(diǎn)

• 輕量級(jí)，同樣起web服務(wù),比apache占用更少的內(nèi)存資源
• 抗并發(fā)，nginx處理請(qǐng)求是異步非阻塞的，支持更多的并發(fā)連接，而apache則是阻塞型的,在高并發(fā)nginx能保持低資源低消耗高性能
• 配置簡(jiǎn)潔
• 高度模塊化設(shè)計(jì)，編寫模塊相對(duì)簡(jiǎn)單
• 社區(qū)活躍

apache 相比nginx的優(yōu)點(diǎn)：

• rewrite ,比nginx的rewrite1強(qiáng)大
• 少bug,nginx的bug相對(duì)較多
• 超穩(wěn)定

9.網(wǎng)站用戶密碼保存

• 明文保存
• 明文hash后保存,如md5
• MD5+Salt方式，這個(gè)salt可以隨機(jī)
• 知乎使用了Bcrypy(好像）加密

10.http和https

http是一種應(yīng)用最為廣泛的協(xié)議，是客戶端和服務(wù)端請(qǐng)求的標(biāo)準(zhǔn)
用于從www服務(wù)器上傳輸超文本到本地的傳輸協(xié)議，它可以讓瀏覽器變的更加高效使網(wǎng)絡(luò)傳輸減少。
https是以安全為目標(biāo)的http通道，簡(jiǎn)單的講就是http安全版，即http的安全版，即http下加了ssl層，http的安全基礎(chǔ)是ssl，因此加密的詳細(xì)內(nèi)容就需要ssl
https協(xié)議的主要作用可以分為兩種：一種是建立安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實(shí)性

兩者區(qū)別

• https協(xié)議需要到ca申請(qǐng)認(rèn)證，一般免費(fèi)認(rèn)證比較少，因?yàn)樾枰恍┵M(fèi)用
• http是超文本傳輸協(xié)議，信息明文傳輸，http則是具有安全性的ssi加密傳輸協(xié)議
• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者80，后者443.
• http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的;https協(xié)議是由ssl+http協(xié)議構(gòu)成的可進(jìn)行加密傳輸，身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全

11.xsrf和xss

• CSRF(Cross-site request forgery)跨站請(qǐng)求偽造
• XSS(Cross Site Scripting)跨站腳本攻擊
  csrf重點(diǎn)在請(qǐng)求，xss重點(diǎn)在腳本

12.SOAP

SOAP（原為Simple Object Access Protocol的首字母縮寫，即簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議）是交換數(shù)據(jù)的一種協(xié)議規(guī)范，使用在計(jì)算機(jī)網(wǎng)絡(luò)Web服務(wù)（web service）中，交換帶結(jié)構(gòu)信息。SOAP為了簡(jiǎn)化網(wǎng)頁(yè)服務(wù)器（Web Server）從XML數(shù)據(jù)庫(kù)中提取數(shù)據(jù)時(shí)，節(jié)省去格式化頁(yè)面時(shí)間，以及不同應(yīng)用程序之間按照HTTP通信協(xié)議，遵從XML格式執(zhí)行資料互換，使其抽象于語(yǔ)言實(shí)現(xiàn)、平臺(tái)和硬件。

13.RPC

RPC（Remote Procedure Call Protocol）——遠(yuǎn)程過(guò)程調(diào)用協(xié)議，它是一種通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開(kāi)發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。
總結(jié):服務(wù)提供的兩大流派.傳統(tǒng)意義以方法調(diào)用為導(dǎo)向通稱RPC。為了企業(yè)SOA,若干廠商聯(lián)合推出webservice,制定了wsdl接口定義,傳輸soap.當(dāng)互聯(lián)網(wǎng)時(shí)代,臃腫SOA被簡(jiǎn)化為http+xml/json.但是簡(jiǎn)化出現(xiàn)各種混亂。以資源為導(dǎo)向,任何操作無(wú)非是對(duì)資源的增刪改查，于是統(tǒng)一的REST出現(xiàn)了.
進(jìn)化的順序: RPC -> SOAP -> RESTful

14.CGI和WSGI

CGI是通用網(wǎng)關(guān)接口，是連接web服務(wù)器和應(yīng)用程序的接口，用戶通過(guò)CGI來(lái)獲取動(dòng)態(tài)數(shù)據(jù)或文件等。 CGI程序是一個(gè)獨(dú)立的程序，它可以用幾乎所有語(yǔ)言來(lái)寫，包括perl，c，lua，python等等。
WSGI, Web Server Gateway Interface，是Python應(yīng)用程序或框架和Web服務(wù)器之間的一種接口，WSGI的其中一個(gè)目的就是讓用戶可以用統(tǒng)一的語(yǔ)言(Python)編寫前后端。

15.中間人攻擊

中間人攻擊（Man-in-the-middle attack，通?？s寫為MITM）是指攻擊者與通訊的兩端分別創(chuàng)建獨(dú)立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認(rèn)為他們正在通過(guò)一個(gè)私密的連接與對(duì)方直接對(duì)話，但事實(shí)上整個(gè)會(huì)話都被攻擊者完全控制。

16.c10k問(wèn)題

所謂c10k問(wèn)題，指的是服務(wù)器同時(shí)支持成千上萬(wàn)個(gè)客戶端的問(wèn)題，也就是concurrent 10 000 connection（這也是c10k這個(gè)名字的由來(lái)）。 推薦: https://my.oschina.net/xianggao/blog/664275

17.mvcc

全稱是Multi-Version Concurrent Control,即版本控制器，在mvcc協(xié)議下，每個(gè)操作會(huì)看到一個(gè)一致性的snapshot,并且可以實(shí)現(xiàn)非阻塞的讀。mvcc允許數(shù)據(jù)具有多個(gè)版本，這個(gè)版本可以是時(shí)間戳或者全局遞增的事物ID,在同一個(gè)時(shí)間點(diǎn)，不同的事物看到的事物是不一樣的。

18.socket

推薦: http://www.360doc.com/content/11/0609/15/5482098_122692444.shtml
Socket=Ip address+ TCP/UDP + port

19.瀏覽器緩存

推薦: http://www.cnblogs.com/skynet/archive/2012/11/28/2792503.html
304 Not Modified

20.Ajax

AJAX,Asynchronous JavaScript and XML（異步的 JavaScript 和 XML）, 是與在不重新加載整個(gè)頁(yè)面的情況下，與服務(wù)器交換數(shù)據(jù)并更新部分網(wǎng)頁(yè)的技術(shù)。

Unix進(jìn)程間的通訊方式

1.管道（Pipe）：管道可用于具有親緣關(guān)系進(jìn)程間的通信，允許一個(gè)進(jìn)程和另一個(gè)與它有共同祖先的進(jìn)程之間進(jìn)行通信。
2.命名管道（named pipe）：命名管道克服了管道沒(méi)有名字的限制，因此，除具有管道所具有的功能外，它還允許無(wú)親緣關(guān)系進(jìn)程間的通信。命名管道在文件系統(tǒng)中有對(duì)應(yīng)的文件名。命名管道通過(guò)命令mkfifo或系統(tǒng)調(diào)用mkfifo來(lái)創(chuàng)建。
3.信號(hào)（Signal）：信號(hào)是比較復(fù)雜的通信方式，用于通知接受進(jìn)程有某種事件發(fā)生，除了用于進(jìn)程間通信外，進(jìn)程還可以發(fā)送信號(hào)給進(jìn)程本身；linux除了支持Unix早期信號(hào)語(yǔ)義函數(shù)sigal外，還支持語(yǔ)義符合Posix.1標(biāo)準(zhǔn)的信號(hào)函數(shù)sigaction（實(shí)際上，該函數(shù)是基于BSD的，BSD為了實(shí)現(xiàn)可靠信號(hào)機(jī)制，又能夠統(tǒng)一對(duì)外接口，用sigaction函數(shù)重新實(shí)現(xiàn)了signal函數(shù)）。
4.消息（Message）隊(duì)列：消息隊(duì)列是消息的鏈接表，包括Posix消息隊(duì)列system V消息隊(duì)列。有足夠權(quán)限的進(jìn)程可以向隊(duì)列中添加消息，被賦予讀權(quán)限的進(jìn)程則可以讀走隊(duì)列中的消息。消息隊(duì)列克服了信號(hào)承載信息量少，管道只能承載無(wú)格式字節(jié)流以及緩沖區(qū)大小受限等缺
5.共享內(nèi)存：使得多個(gè)進(jìn)程可以訪問(wèn)同一塊內(nèi)存空間，是最快的可用IPC形式。是針對(duì)其他通信機(jī)制運(yùn)行效率較低而設(shè)計(jì)的。往往與其它通信機(jī)制，如信號(hào)量結(jié)合使用，來(lái)達(dá)到進(jìn)程間的同步及互斥。
6.內(nèi)存映射（mapped memory）：內(nèi)存映射允許任何多個(gè)進(jìn)程間通信，每一個(gè)使用該機(jī)制的進(jìn)程通過(guò)把一個(gè)共享的文件映射到自己的進(jìn)程地址空間來(lái)實(shí)現(xiàn)它。
7.信號(hào)量（semaphore）：主要作為進(jìn)程間以及同一進(jìn)程不同線程之間的同步手段。
8.套接口（Socket）：更為一般的進(jìn)程間通信機(jī)制，可用于不同機(jī)器之間的進(jìn)程間通信。起初是由Unix系統(tǒng)的BSD分支開(kāi)發(fā)出來(lái)的，但現(xiàn)在一般可以移植到其它類Unix系統(tǒng)上：Linux和System V的變種都支持套接字。