io模型

有哪些網(wǎng)絡(luò)io模型鸥昏？哪些網(wǎng)絡(luò)操作可以是異步的存和？

常見(jiàn)的網(wǎng)絡(luò) IO 模型有：同步阻塞 IO，同步非阻塞 IO蜓席，多路復(fù)用 IO 和異步 IO器一。

異步網(wǎng)絡(luò)操作包括：連接請(qǐng)求，數(shù)據(jù)發(fā)送和數(shù)據(jù)接收厨内。(不確定)

select/poll/epoll

select/poll與epoll區(qū)別

• select 和 poll 是兩個(gè)系統(tǒng)調(diào)用祈秕，用于監(jiān)視多個(gè)文件描述符，以檢查它們是否準(zhǔn)備好 I/O雏胃。
  epoll 是 select 和 poll 的更高效替代方案请毛，在 Linux 內(nèi)核 2.6 中引入。它使用事件驅(qū)動(dòng)方法監(jiān)視文件描述符瞭亮，提供更好的可擴(kuò)展性和性能方仿。

• select、poll 和 epoll 主要的區(qū)別如下：
  可擴(kuò)展性：select 和 poll 對(duì)監(jiān)視的文件描述符數(shù)量有限制统翩，而 epoll 可以監(jiān)視數(shù)以千計(jì)的文件描述符仙蚜。
  性能：epoll 比 select 和 poll 更快，特別是在監(jiān)視大量文件描述符時(shí)唆缴。
  監(jiān)視模式：select 和 poll 的監(jiān)視模式有限，而 epoll 提供多種監(jiān)視模式黍翎，包括邊緣觸發(fā)和級(jí)別觸發(fā)面徽。

總體來(lái)說(shuō)，epoll比select和poll更高效，更靈活趟紊，資源消耗更小氮双，是一種更優(yōu)秀的I/O多路復(fù)用機(jī)制。

• 其他補(bǔ)充(select和epoll對(duì)比)：
  原理不同：select是阻塞式的霎匈，每次調(diào)用都會(huì)重新遍歷所有文件描述符戴差；而epoll是非阻塞式的，它內(nèi)部使用紅黑樹(shù)維護(hù)所有的文件描述符铛嘱，每次調(diào)用只需要遍歷發(fā)生變化的文件描述符暖释。
  
  效率不同：select的效率較低，因?yàn)樗看握{(diào)用都需要重新遍歷所有文件描述符墨吓；而epoll的效率較高球匕，因?yàn)樗鼉?nèi)部使用紅黑樹(shù)維護(hù)所有的文件描述符，每次調(diào)用只需要遍歷發(fā)生變化的文件描述符帖烘。
  
  支持的文件描述符數(shù)量不同：select支持的文件描述符數(shù)量有限制亮曹，在不同的操作系統(tǒng)中限制不同；而epoll支持的文件描述符數(shù)量沒(méi)有限制秘症。
  
  支持的事件類型不同：select支持讀照卦、寫(xiě)、異常事件乡摹；而epoll支持讀役耕、寫(xiě)、異常趟卸、邊沿觸發(fā)蹄葱、水平觸發(fā)等多種事件。

TUP/UDP

TCP三次握手锄列，四次揮手图云，發(fā)送的包名，狀態(tài)圖邻邮，對(duì)應(yīng)的POSIX API

• TCP三次握手：
  第一次握手：客戶端發(fā)送SYN（Synchronize）請(qǐng)求竣况，表示請(qǐng)求建立連接。
  第二次握手：服務(wù)器收到請(qǐng)求后筒严，發(fā)送SYN+ACK（Synchronize+Acknowledgment）應(yīng)答丹泉，表示同意建立連接。
  第三次握手：客戶端收到應(yīng)答后鸭蛙，發(fā)送ACK（Acknowledgment）確認(rèn)摹恨，表示建立連接完成。

• TCP四次揮手：
  第一次揮手：客戶端發(fā)送FIN（Finish）請(qǐng)求娶视，表示請(qǐng)求結(jié)束連接晒哄。
  第二次揮手：服務(wù)器收到請(qǐng)求后睁宰，發(fā)送ACK（Acknowledgment）應(yīng)答，表示收到請(qǐng)求寝凌。
  第三次揮手：服務(wù)器發(fā)送FIN（Finish）請(qǐng)求柒傻，表示請(qǐng)求結(jié)束連接。
  第四次揮手：客戶端收到請(qǐng)求后较木，發(fā)送ACK（Acknowledgment）確認(rèn)红符，表示結(jié)束連接完成。

• 發(fā)送的包名：
  SYN（Synchronize）請(qǐng)求
  SYN+ACK（Synchronize+Acknowledgment）應(yīng)答
  ACK（Acknowledgment）確認(rèn)
  FIN（Finish）請(qǐng)求

• 狀態(tài)圖：
  1.三次握手過(guò)程中伐债，客戶端和服務(wù)端的狀態(tài)變化如下：
  客戶端：CLOSED -> SYN_SENT -> ESTABLISHED
  服務(wù)端：CLOSED -> LISTEN -> SYN_RCVD -> ESTABLISHED
  2.四次揮手過(guò)程中预侯，客戶端和服務(wù)端的狀態(tài)變化如下：
  客戶端：ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED
  服務(wù)端：ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

• 對(duì)應(yīng)的POSIX API：
  socket()：創(chuàng)建套接字。(創(chuàng)建一個(gè)通信端點(diǎn)泳赋，為連接做準(zhǔn)備)
  bind()：綁定套接字
  listen()：監(jiān)聽(tīng)套接字雌桑。(服務(wù)器監(jiān)聽(tīng)連接請(qǐng)求)
  accept()：接收連接請(qǐng)求。(服務(wù)器接受連接請(qǐng)求)
  connect()：發(fā)起連接請(qǐng)求祖今。(客戶端發(fā)起連接請(qǐng)求)
  send()/recv()：發(fā)送/接收數(shù)據(jù)
  close()：關(guān)閉套接字校坑。(關(guān)閉連接)

TCP鏈接建立和斷開(kāi)的過(guò)程，狀態(tài)轉(zhuǎn)移

• TCP 鏈接建立和斷開(kāi)的過(guò)程如下：
  1.建立連接：
  客戶端發(fā)送 SYN 報(bào)文千诬，表示請(qǐng)求建立連接耍目。
  服務(wù)端收到 SYN 報(bào)文，回復(fù) ACK 和 SYN 報(bào)文徐绑，表示同意建立連接邪驮。
  客戶端收到 ACK 和 SYN 報(bào)文，回復(fù) ACK 報(bào)文傲茄，表示確認(rèn)連接建立毅访。
  2.斷開(kāi)連接：
  一方發(fā)送 FIN 報(bào)文，表示請(qǐng)求斷開(kāi)連接盘榨。
  另一方收到 FIN 報(bào)文喻粹，回復(fù) ACK 報(bào)文，表示同意斷開(kāi)連接草巡。
  發(fā)送 FIN 報(bào)文的一方再次回復(fù) ACK 報(bào)文守呜，表示確認(rèn)連接斷開(kāi)。

• TCP 連接狀態(tài)轉(zhuǎn)移如下：
  CLOSED：未建立連接狀態(tài)山憨。
  SYN_SENT：客戶端已發(fā)送 SYN 報(bào)文查乒，等待服務(wù)端回復(fù)。
  SYN_RCVD：服務(wù)端已收到 SYN 報(bào)文郁竟，等待客戶端回復(fù) ACK玛迄。
  ESTABLISHED：連接建立成功，可以進(jìn)行數(shù)據(jù)傳輸棚亩。
  FIN_WAIT_1：客戶端已發(fā)送 FIN 報(bào)文蓖议，等待服務(wù)端回復(fù) ACK藻肄。
  FIN_WAIT_2：服務(wù)端已回復(fù) ACK，等待服務(wù)端發(fā)送 FIN拒担。
  TIME_WAIT：等待足夠時(shí)間以確保所有數(shù)據(jù)已傳達(dá)，然后進(jìn)入 CLOSED 狀態(tài)攻询。
  CLOSE_WAIT：服務(wù)端已發(fā)

SYN Flood攻擊从撼，防御措施

• SYN Flood 攻擊(SYN洪水攻擊、半開(kāi)連接攻擊)：這是一種 DDoS 攻擊钧栖，利用 TCP 連接序列（“三次握手”）的弱點(diǎn)低零，向目標(biāo)系統(tǒng)發(fā)送大量 SYN 請(qǐng)求，使其無(wú)法處理合法請(qǐng)求拯杠。（攻擊者將可擊垮目標(biāo)服務(wù)器計(jì)算機(jī)上的所有可用端口掏婶，導(dǎo)致目標(biāo)設(shè)備在響應(yīng)合法流量時(shí)表現(xiàn)遲鈍乃至全無(wú)響應(yīng)。）

• 首包丟棄和源認(rèn)證兩種手段結(jié)合潭陪，對(duì)于防御SYN Flood（特別是不斷變換源IP和源端口的虛假源攻擊）非常有效雄妥。
  通常情況下客戶端發(fā)送SYN報(bào)文后如果在一定時(shí)間沒(méi)有收到服務(wù)器的SYN-ACK應(yīng)答，客戶端會(huì)重新發(fā)送SYN報(bào)文依溯。Anti-DDoS系統(tǒng)會(huì)丟棄掉收到的第一個(gè)SYN報(bào)文老厌。SYN Flood攻擊時(shí)，黑客發(fā)送的絕大多數(shù)是變?cè)吹腟YN報(bào)文黎炉，所有的SYN報(bào)文對(duì)于Anti-DDoS系統(tǒng)來(lái)說(shuō)都是首包枝秤，都將被直接丟棄。如果客戶端重傳了SYN報(bào)文慷嗜，Anti-DDoS系統(tǒng)再對(duì)該報(bào)文進(jìn)行源認(rèn)證淀弹。如此一來(lái)，大大減少了Anti-DDoS系統(tǒng)代答的壓力庆械。

• 補(bǔ)充：源認(rèn)證和首包丟棄
  源認(rèn)證
  Anti-DDoS系統(tǒng)攔截客戶端發(fā)送的SYN報(bào)文薇溃，代替服務(wù)器向客戶端發(fā)送SYN-ACK報(bào)文，如果客戶端不應(yīng)答干奢，則認(rèn)為該客戶端為虛假源痊焊；如果客戶端應(yīng)答，則Anti-DDoS系統(tǒng)認(rèn)為該客戶端為真實(shí)源忿峻，并將其IP地址加入白名單薄啥，在一段時(shí)間允許該源發(fā)送的所有SYN報(bào)文通過(guò)，也不做代答逛尚。
  首包丟棄
  如果Anti-DDoS系統(tǒng)代替服務(wù)器應(yīng)答了所有的SYN Flood攻擊報(bào)文垄惧，那么性能瓶頸僅僅是從服務(wù)器轉(zhuǎn)移到了Anti-DDoS系統(tǒng)而已。一旦Anti-DDoS系統(tǒng)的系統(tǒng)資源耗盡绰寞，攻擊依舊會(huì)透?jìng)鞯椒?wù)器到逊，而且大量反彈的SYN-ACK報(bào)文也會(huì)對(duì)網(wǎng)絡(luò)造成一定的壓力铣口。Anti-DDoS系統(tǒng)利用首包丟棄來(lái)解決這個(gè)問(wèn)題

TCP和UDP區(qū)別？TCP如何保證可靠性觉壶？對(duì)方是否存活(心跳檢測(cè))脑题？

• TCP和UDP區(qū)別：
  TCP（Transmission Control Protocol）是一種面向連接的、可靠的铜靶、基于字節(jié)流的傳輸層協(xié)議叔遂。它保證數(shù)據(jù)的可靠傳輸，并且提供流量控制和擁塞控制争剿。
  UDP（User Datagram Protocol）是一種無(wú)連接的已艰、不可靠的、基于數(shù)據(jù)報(bào)的傳輸層協(xié)議蚕苇。它不保證數(shù)據(jù)的可靠傳輸哩掺，沒(méi)有流量控制和擁塞控制。
  其他補(bǔ)充：
  TCP是面向連接的協(xié)議涩笤，保證數(shù)據(jù)的可靠傳輸嚼吞。UDP是面向無(wú)連接的協(xié)議，不保證數(shù)據(jù)的可靠性蹬碧。
  TCP是流式協(xié)議誊薄，把數(shù)據(jù)分成多個(gè)數(shù)據(jù)報(bào)，并且保證每個(gè)數(shù)據(jù)報(bào)都能到達(dá)對(duì)方锰茉。UDP是數(shù)據(jù)報(bào)協(xié)議呢蔫，不保證數(shù)據(jù)的順序。
  TCP的傳輸速度比UDP慢飒筑，因?yàn)門CP需要處理更多的握手和確認(rèn)信息片吊。
  TCP是適用于需要長(zhǎng)連接的應(yīng)用，如文件傳輸协屡、電子郵件等俏脊。UDP是適用于需要快速傳輸?shù)膽?yīng)用柒昏，如語(yǔ)音笙什、視頻等诸蚕。

• TCP如何保證可靠性：
  除了三次握手保證可靠性外工坊；
  通過(guò)確認(rèn)機(jī)制，確保數(shù)據(jù)能夠到達(dá)對(duì)方姻蚓。
  通過(guò)重傳機(jī)制舌厨，確保數(shù)據(jù)能夠準(zhǔn)確傳輸缀踪。
  通過(guò)滑動(dòng)窗口機(jī)制盈匾，確保數(shù)據(jù)能夠快速傳輸腾务。
  
  或者回答(推薦)：
  數(shù)據(jù)校驗(yàn)：通過(guò)數(shù)據(jù)校驗(yàn)確保數(shù)據(jù)的完整性。
  流量控制：通過(guò)滑動(dòng)窗口機(jī)制避免接收方緩存溢出削饵。
  重傳機(jī)制：如果發(fā)送方發(fā)現(xiàn)數(shù)據(jù)丟失岩瘦，會(huì)重傳丟失的數(shù)據(jù)未巫。
  擁塞控制：通過(guò)慢啟動(dòng)、擁塞避免等算法避免網(wǎng)絡(luò)擁塞启昧。

• 對(duì)方是否存活（心跳檢測(cè)）：
  可以通過(guò)發(fā)送心跳消息來(lái)檢測(cè)對(duì)方是否存活叙凡。如果一段時(shí)間內(nèi)沒(méi)有收到心跳消息，則判斷對(duì)方不存在密末。這樣可以確保連接的實(shí)時(shí)性狭姨。（心跳檢測(cè)通常由應(yīng)用層實(shí)現(xiàn)，不是TCP協(xié)議的一部分苏遥。）

TCP中的流量控制原理

TCP 中的流量控制是通過(guò)維護(hù)發(fā)送窗口來(lái)實(shí)現(xiàn)的。發(fā)送窗口是一個(gè)數(shù)字赡模，表示發(fā)送方可以發(fā)送的最大字節(jié)數(shù)田炭。接收方根據(jù)自己的緩存情況通過(guò) ACK 報(bào)文告訴發(fā)送方可以接收的數(shù)據(jù)量。發(fā)送方根據(jù)接收到的 ACK 報(bào)文動(dòng)態(tài)調(diào)整發(fā)送窗口漓柑，以保證數(shù)據(jù)不會(huì)被緩存過(guò)多教硫。

TCP的擁塞控制原理？實(shí)現(xiàn)擁塞控制的主要算法有哪些辆布？

• TCP 的擁塞控制原理是通過(guò)監(jiān)測(cè)網(wǎng)絡(luò)中數(shù)據(jù)包丟失和延遲情況來(lái)評(píng)估網(wǎng)絡(luò)擁塞程度瞬矩，并調(diào)整發(fā)送窗口大小來(lái)降低網(wǎng)絡(luò)擁塞。
  （或者：通過(guò)監(jiān)測(cè)網(wǎng)絡(luò)狀況锋玲，動(dòng)態(tài)調(diào)整發(fā)送窗口景用，以保證網(wǎng)絡(luò)的有效利用，避免網(wǎng)絡(luò)擁塞惭蹂。）

• 常見(jiàn)的 TCP 擁塞控制算法有(4種）：
  快速重傳：當(dāng)發(fā)現(xiàn)數(shù)據(jù)包丟失時(shí)伞插，快速重傳算法立即重新發(fā)送丟失的數(shù)據(jù)包。
  快速恢復(fù)：當(dāng)發(fā)現(xiàn)數(shù)據(jù)包丟失時(shí)盾碗，快速恢復(fù)算法通過(guò)減小發(fā)送窗口大小來(lái)降低網(wǎng)絡(luò)擁塞媚污。
  慢啟動(dòng)：慢啟動(dòng)算法通過(guò)慢慢增加發(fā)送窗口大小來(lái)確保網(wǎng)絡(luò)穩(wěn)定。
  擁塞避免：擁塞避免算法通過(guò)監(jiān)測(cè)網(wǎng)絡(luò)狀況廷雅，并在發(fā)現(xiàn)擁塞時(shí)減小發(fā)送窗口大小耗美，以降低網(wǎng)絡(luò)擁塞。

UDP能保證數(shù)據(jù)包順序嗎?
UDP怎么實(shí)現(xiàn)TCP的擁塞控制航缀？

• 不能商架。UDP是面向無(wú)連接的協(xié)議，不像TCP那樣有確認(rèn)機(jī)制和重傳機(jī)制芥玉，所以不保證數(shù)據(jù)的順序甸私。UDP數(shù)據(jù)報(bào)的接收順序可能與發(fā)送順序不同，因?yàn)閁DP不保證數(shù)據(jù)的可靠性飞傀。
  如果需要保證數(shù)據(jù)包的順序皇型，可以使用TCP協(xié)議诬烹。或者如果需要保證數(shù)據(jù)包的順序弃鸦，需要在應(yīng)用層自己處理绞吁。

• UDP不支持擁塞控制，因?yàn)樗且环N無(wú)連接的協(xié)議唬格。如果需要擁塞控制家破，可以使用TCP或者在應(yīng)用層上實(shí)現(xiàn)自己的擁塞控制算法。

TCP的timeout狀態(tài)含義购岗，怎么避免timeout汰聋？TIME-WAIT()狀態(tài)下的等待時(shí)間是多少？為什么（即TIME_WAIT的作用）喊积？
四次揮手中烹困，TIME-WAIT狀態(tài)是在哪一步？

• TCP timeout 狀態(tài)：在傳輸數(shù)據(jù)時(shí)乾吻，如果一段時(shí)間內(nèi)未收到對(duì)方的 ACK 確認(rèn)髓梅，則認(rèn)為該數(shù)據(jù)已經(jīng)丟失，將重新發(fā)送該數(shù)據(jù)绎签。(指在數(shù)據(jù)傳輸過(guò)程中枯饿，由于網(wǎng)絡(luò)故障或其他原因，導(dǎo)致TCP連接失效诡必，而進(jìn)入超時(shí)狀態(tài)奢方。)

• 避免 timeout：
  增加 timeout 時(shí)間，但這會(huì)增加網(wǎng)絡(luò)的延遲爸舒。
  增加數(shù)據(jù)的重發(fā)次數(shù)袱巨，但這會(huì)增加網(wǎng)絡(luò)的流量。
  使用更高效的網(wǎng)絡(luò)協(xié)議碳抄，如 TCP-SACK愉老、TCP-FACK 等。

• TIME-WAIT 狀態(tài)下的等待時(shí)間是 2 MSL（Maximum Segment Lifetime）剖效，通常為 2 分鐘（TCP協(xié)議規(guī)定嫉入，在TIME-WAIT狀態(tài)下，系統(tǒng)需要等待2倍的最大報(bào)文生存時(shí)間）璧尸。該狀態(tài)等待時(shí)間是為了確保發(fā)送方的最后一個(gè)數(shù)據(jù)包已經(jīng)被對(duì)方接收咒林，避免未接收的數(shù)據(jù)包被誤判為新的數(shù)據(jù)包。

• TIME-WAIT狀態(tài)是在四次握手的第四步爷光。

計(jì)算機(jī)網(wǎng)絡(luò)結(jié)構(gòu)

OSI七層垫竞？TCP/IP五層？

• OSI 七層模型：
  物理層：描述網(wǎng)絡(luò)的物理設(shè)備，如網(wǎng)絡(luò)接口卡欢瞪、電纜等活烙。
  數(shù)據(jù)鏈路層：負(fù)責(zé)數(shù)據(jù)的傳輸和錯(cuò)誤檢測(cè)。
  網(wǎng)絡(luò)層：負(fù)責(zé)數(shù)據(jù)的路由和網(wǎng)絡(luò)地址分配遣鼓。
  傳輸層：負(fù)責(zé)數(shù)據(jù)的傳輸啸盏，并且提供可靠的數(shù)據(jù)傳輸服務(wù)。
  會(huì)話層：負(fù)責(zé)數(shù)據(jù)傳輸?shù)耐胶凸芾怼?br> 表示層：負(fù)責(zé)數(shù)據(jù)的編碼和解碼骑祟。
  應(yīng)用層：負(fù)責(zé)應(yīng)用程序與網(wǎng)絡(luò)間的通信回懦。

• TCP/IP 五層模型：
  物理層：與 OSI 模型的物理層相同。
  數(shù)據(jù)鏈路層：與 OSI 模型的數(shù)據(jù)鏈路層相同次企。
  網(wǎng)絡(luò)層：與 OSI 模型的網(wǎng)絡(luò)層相同怯晕。
  傳輸層：與 OSI 模型的傳輸層相同。
  應(yīng)用層：合并了 OSI 模型的會(huì)話層缸棵、表示層和應(yīng)用層舟茶。

計(jì)算機(jī)網(wǎng)絡(luò)的七層結(jié)構(gòu)、五層結(jié)構(gòu)蛉谜、四層結(jié)構(gòu)？
http崇堵、tcp分別屬于哪一層型诚？

計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分為3種：OSI體系結(jié)構(gòu)（七層），TCP/IP體系結(jié)構(gòu)（四層）鸳劳，五層體系結(jié)構(gòu)狰贯。

• OSI體系結(jié)構(gòu)（七層）: 概念清楚，理論也比較完整赏廓，但是它既復(fù)雜又不實(shí)用涵紊。
• TCP/IP體系結(jié)構(gòu)（四層）:TCP/IP是一個(gè)四層體系結(jié)構(gòu)，得到了廣泛的運(yùn)用幔摸。
• 五層體系結(jié)構(gòu):為了方便學(xué)習(xí)摸柄，折中OSI體系結(jié)構(gòu)和TCP/IP體系結(jié)構(gòu)，綜合二者的優(yōu)點(diǎn)既忆，這樣既簡(jiǎn)潔驱负，又能將概念講清楚。

image.png

HTTP 屬于應(yīng)用層患雇，是一種應(yīng)用層協(xié)議跃脊，負(fù)責(zé)在 Web 上進(jìn)行數(shù)據(jù)傳輸。
TCP 屬于傳輸層苛吱，是一種傳輸層協(xié)議酪术，負(fù)責(zé)提供可靠的數(shù)據(jù)傳輸服務(wù)。

http與https的區(qū)別翠储？https的加密方式绘雁？

• HTTP 和 HTTPS 的區(qū)別：
  1.安全性：HTTP 是明文傳輸橡疼，不安全；HTTPS 則使用 SSL/TLS 加密咧七，提供安全性衰齐。
  2.端口號(hào)：HTTP 的默認(rèn)端口號(hào)是 80；HTTPS 的默認(rèn)端口號(hào)是 443继阻。
  3.證書(shū)：HTTPS 需要使用數(shù)字證書(shū)耻涛，證明網(wǎng)站的合法性。
• HTTPS 加密方式：
  HTTPS 使用 SSL/TLS 協(xié)議進(jìn)行加密瘟檩，其中 SSL（Secure Sockets Layer）是一種網(wǎng)絡(luò)安全協(xié)議抹缕，TLS（Transport Layer Security）是 SSL 的繼任者。
  它們使用對(duì)稱加密墨辛、非對(duì)稱加密和散列算法等技術(shù)卓研，保證數(shù)據(jù)在傳輸過(guò)程中不被竊取和篡改。

HTTP狀態(tài)碼有哪些

• HTTP 狀態(tài)碼分為 5 個(gè)類別：
  1xx：信息性狀態(tài)碼睹簇，表示接收到請(qǐng)求并繼續(xù)處理奏赘。
  2xx：成功狀態(tài)碼，表示請(qǐng)求已成功處理太惠。常見(jiàn)的有 200 OK磨淌、201 Created 等。
  3xx：重定向狀態(tài)碼凿渊，表示需要進(jìn)一步操作以完成請(qǐng)求梁只。常見(jiàn)的有 301 Moved Permanently、302 Found 等埃脏。
  4xx：客戶端錯(cuò)誤狀態(tài)碼搪锣，表示客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)。常見(jiàn)的有 400 Bad Request彩掐、401 Unauthorized 等构舟。
  5xx：服務(wù)器錯(cuò)誤狀態(tài)碼，表示服務(wù)器無(wú)法完成對(duì)請(qǐng)求的處理堵幽。常見(jiàn)的有 500 Internal Server Error旁壮、503 Service Unavailable 等。

• 常見(jiàn)的 HTTP 狀態(tài)碼：
  200 OK：請(qǐng)求成功谐檀。
  201 Created：請(qǐng)求成功抡谐，并創(chuàng)建了新的資源。
  204 No Content：請(qǐng)求成功桐猬，但沒(méi)有返回任何內(nèi)容麦撵。
  301 Moved Permanently：請(qǐng)求的資源已永久移動(dòng)到新位置。
  302 Found：請(qǐng)求的資源臨時(shí)移動(dòng)到新位置。
  304 Not Modified：請(qǐng)求的資源未改變免胃，可以使用緩存音五。
  400 Bad Request：請(qǐng)求錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤羔沙。
  401 Unauthorized：請(qǐng)求未授權(quán)躺涝，需要用戶驗(yàn)證。
  403 Forbidden：請(qǐng)求被禁止扼雏，禁止訪問(wèn)坚嗜。
  404 Not Found：請(qǐng)求的資源不存在。
  500 Internal Server Error：服務(wù)器內(nèi)部錯(cuò)誤诗充。

GET 和 POST的區(qū)別苍蔬？本質(zhì)區(qū)別？

• 本質(zhì)區(qū)別
  GET 和 POST是HTTP協(xié)議中的兩種請(qǐng)求方法蝴蜓，GET 和POST 方法沒(méi)有本質(zhì)區(qū)別碟绑，僅報(bào)文格式不同。GET請(qǐng)求用于獲取資源茎匠，而POST請(qǐng)求用于向服務(wù)器發(fā)送數(shù)據(jù)格仲，如用戶輸入。
  GET：GET 是一種用于從服務(wù)器檢索數(shù)據(jù)的 HTTP 方法诵冒。當(dāng)您在網(wǎng)頁(yè)瀏覽器中輸入 URL 時(shí)凯肋，瀏覽器會(huì)向服務(wù)器發(fā)送一個(gè) GET 請(qǐng)求，請(qǐng)求指定的資源造烁。
  POST：POST 是另一種用于向服務(wù)器發(fā)送數(shù)據(jù)以進(jìn)行處理的 HTTP 方法否过。與 GET 不同午笛，POST 請(qǐng)求可以在請(qǐng)求體中包含數(shù)據(jù)惭蟋，這允許進(jìn)行更復(fù)雜的操作，例如提交表單药磺。

• 區(qū)別：
  get比post更快（原因見(jiàn)下）
  post發(fā)送的數(shù)據(jù)更大（get有url長(zhǎng)度限制）
  post能發(fā)送更多的數(shù)據(jù)類型（get只能發(fā)送ASCII字符）
  post更安全（不會(huì)作為url的一部分告组，不會(huì)被緩存、保存在服務(wù)器日志癌佩、以及瀏覽器瀏覽記錄中）

• 為什么get比post更快木缝？
  1.post請(qǐng)求包含更多的請(qǐng)求頭
  2.最重要的一條，post在真正接收數(shù)據(jù)之前會(huì)先將請(qǐng)求頭發(fā)送給服務(wù)器進(jìn)行確認(rèn)围辙，然后才真正發(fā)送數(shù)據(jù)
  3.get會(huì)將數(shù)據(jù)緩存起來(lái)

子網(wǎng)掩碼的作用我碟？

子網(wǎng)掩碼是一個(gè)32位地址，是與IP地址結(jié)合使用的一種技術(shù)姚建。 它的主要作用有兩個(gè)矫俺，一是用于屏蔽IP地址的一部分以區(qū)別網(wǎng)絡(luò)標(biāo)識(shí)和主機(jī)標(biāo)識(shí)，并說(shuō)明該IP地址是在局域網(wǎng)上，還是在遠(yuǎn)程網(wǎng)上厘托。 二是用于將一個(gè)大的IP網(wǎng)絡(luò)劃分為若干小的子網(wǎng)絡(luò)友雳。 使用子網(wǎng)是為了減少IP的浪費(fèi)。

常見(jiàn)的網(wǎng)絡(luò)協(xié)議有哪些铅匹？
說(shuō)一下DNS協(xié)議常見(jiàn)網(wǎng)絡(luò)協(xié)議

• 常見(jiàn)的網(wǎng)絡(luò)協(xié)議
  TCP/IP
  HTTP
  FTP
  SMTP
  DNS
  DHCP
  IPsec
  SSL/TLS

• DNS是一種可以將域名和IP地址相互映射的以層次結(jié)構(gòu)分布的數(shù)據(jù)庫(kù)系統(tǒng)押赊。DNS系統(tǒng)采用遞歸查詢請(qǐng)求的方式來(lái)響應(yīng)用戶的查詢,為互聯(lián)網(wǎng)的運(yùn)行提供關(guān)鍵性的基礎(chǔ)服務(wù)

網(wǎng)絡(luò)編程

socket函數(shù)介紹？ socket編程介紹包斑？ socket 基礎(chǔ) API 的使用流礁？

• socket 函數(shù)是用于創(chuàng)建網(wǎng)絡(luò)套接字的函數(shù)，套接字是網(wǎng)絡(luò)編程的基礎(chǔ)舰始。

• socket 編程是一種網(wǎng)絡(luò)編程方式崇棠，用于在兩臺(tái)計(jì)算機(jī)之間進(jìn)行通信。它通過(guò)使用套接字實(shí)現(xiàn)丸卷，以通過(guò)網(wǎng)絡(luò)發(fā)送和接收數(shù)據(jù)枕稀。

• 基礎(chǔ) socket API 包括：
  socket()：創(chuàng)建套接字
  bind()：將套接字與特定的 IP 地址和端口號(hào)綁定
  listen()：監(jiān)聽(tīng)套接字，等待連接請(qǐng)求
  accept()：接受客戶端連接請(qǐng)求
  connect()：連接到服務(wù)器套接字
  send()：向連接的客戶端發(fā)送數(shù)據(jù)
  recv()：從連接的客戶端接收數(shù)據(jù)
  close()：關(guān)閉套接字
  這些 API 函數(shù)通常用于創(chuàng)建網(wǎng)絡(luò)客戶端和服務(wù)器程序谜嫉。

reactor模式和preactor模式區(qū)別

• (答案一)Reactor模式是基于同步I/O的萎坷，而Proactor模式基于異步I/O相關(guān)的。
  
  在Reactor模式中沐兰，事件分離者等待某個(gè)事件或者可應(yīng)用或個(gè)操作的狀態(tài)發(fā)生（比如文件描述符可讀寫(xiě)哆档，或者是socket可讀寫(xiě)），等待后住闯，分離者就把這個(gè)事件傳給事先注冊(cè)的事件處理函數(shù)或者回調(diào)函數(shù)瓜浸，由后者來(lái)做實(shí)際的讀寫(xiě)操作。
  
  而在Proactor模式中比原，事件處理者(或者代由事件分離者發(fā)起)直接發(fā)起一個(gè)異步讀寫(xiě)操作(相當(dāng)于請(qǐng)求)插佛，而實(shí)際的工作是由操作系統(tǒng)來(lái)完成的。發(fā)起時(shí)量窘，需要提供的參數(shù)包括用于存放讀到數(shù)據(jù)的緩存區(qū)雇寇，讀的數(shù)據(jù)大小，或者用于存放外發(fā)數(shù)據(jù)的緩存區(qū)蚌铜，以及這個(gè)請(qǐng)求完后的回調(diào)函數(shù)等信息锨侯。事件分離者得知了這個(gè)請(qǐng)求，它默默等待這個(gè)請(qǐng)求的完成冬殃，然后轉(zhuǎn)發(fā)完成事件給相應(yīng)的事件處理者或者回調(diào)囚痴。
  這種異步模式的典型實(shí)現(xiàn)是基于操作系統(tǒng)底層異步API的，所以我們可稱之為“系統(tǒng)級(jí)別”的或者“真正意義上”的異步审葬，因?yàn)榫唧w的讀寫(xiě)是由操作系統(tǒng)代勞的深滚。

• (答案二)Reactor 模式和 Proactor 模式是兩種不同的 I/O 多路復(fù)用技術(shù)骂束。
  
  Reactor 模式：在 Reactor 模式中，程序等待事件的到來(lái)成箫，并在事件到達(dá)時(shí)執(zhí)行相應(yīng)的處理展箱。它是一種同步 I/O 模型，因?yàn)樗荒茉谑录竭_(dá)時(shí)執(zhí)行處理蹬昌。
  
  Proactor 模式：Proactor 模式是一種異步 I/O 模型混驰，它允許程序在不等待事件到達(dá)的情況下繼續(xù)執(zhí)行。在 Proactor 模式中皂贩，操作系統(tǒng)通知程序事件已完成栖榨，而不是等待程序詢問(wèn)事件的狀態(tài)。
  
  總的來(lái)說(shuō)明刷，Reactor 模式適用于單線程環(huán)境婴栽，而 Proactor 模式適用于多線程環(huán)境。