1、Cookie的實現(xiàn)原理？

參考文章：

• Http Cookie機制及Cookie的實現(xiàn)原理
• Cookie 實現(xiàn)的原理
• Cookie的工作原理和應用詳解

Cookie 工作原理如圖所示：

執(zhí)行流程：

• 瀏覽器向服務器發(fā)送請求，服務器需要創(chuàng)建 cookie，服務器會通過響應攜帶 cookie，在產(chǎn)生響應時會產(chǎn)生 Set-Cookie 響應頭，從而將 cookie 信息傳遞給了瀏覽器；
• 當瀏覽器再次向服務器發(fā)送請求時，會產(chǎn)生 cookie 請求頭，將之前服務器的 cookie 信息再次發(fā)送給了服務器，然后服務器根據(jù) cookie 信息跟蹤客戶端狀態(tài)。

Cookie 創(chuàng)建：

// 用響應創(chuàng)建Cookie，等價于 response.addHeader("set-cookie", "name=value");
Cookie cookie = new Cookie(String name, String value); // Cookie: name=value
cookie.setMaxAge(seconds); // 設(shè)置Cookie的生命周期
cookie.setPath("/"); // 設(shè)置Cookie的共享范圍
response.addCookie(cookie); // 添加1個Cookie

Cookie 獲?。?/p>

// 用請求獲取Cookie
Cookie[] cookies = request.getCookies(); // 獲取Cookies返回數(shù)組
// 需遍歷
cookie.getName(); // 獲取鍵
cookie.getValue(); // 獲取值

Cookie 修改：

// 修改Cookie
cookie.setValue(String name);

2、TCP斷開連接時，通信雙方的狀態(tài)變化？

參考文章：

TCP的三次握手與四次揮手

這道題是我在字節(jié)跳動一面時候遇到的問題，我以為會先從三次握手、四次揮手開始問，沒想到面試官不按常理出牌，直接問我 TCP 通信雙方的狀態(tài)變化。

這道題的答案，直接看上面提供的參考文章，講的非常透徹，也非常容易理解，只需要靜下心看完它！

3、GC垃圾回收時，什么情況下會Stop The World？

在每次 FUll GC 的時候都會 Stop The World (STW)，即，掛起其他所有除了 GC 之外的線程，只讓 GC 垃圾回收線程工作，Young GC 不會觸發(fā) Stop The World。

• CMS 垃圾收集器：
  • 新生代：不會觸發(fā) STW。
  • 老年代：會觸發(fā) 2 次 STW，初始標記 和 重新標記 會觸發(fā)。當年老代達到特定的占用比例時，CMS 開始執(zhí)行。
• G1 垃圾收集器：
  • 新生代：新生對象會被疏散（復制、移動）到一個或多個 Survivor 幸存區(qū)域。如果對象達到晉升總閾值，對象會晉升到年老代區(qū)域，這時候會觸發(fā)一次 STW 。
  • 老年代：G1 老年代垃圾回收和 CMS 一樣，會觸發(fā) 2 次 STW，初始標記 、重新標記、清理、復制 時，會觸發(fā) STW。

4、堆和棧的區(qū)別？

堆：

堆是一種常用的樹形結(jié)構(gòu)，是一種特殊的完全二叉樹，當且僅當滿足所有節(jié)點的值總是不大于或不小于其父節(jié)點的值的完全二叉樹被稱之為堆。堆的這一特性稱之為堆序性。因此，在一個堆中，根節(jié)點是最大（或最?。┕?jié)點。如果根節(jié)點最小，稱之為小頂堆（或小根堆），如果根節(jié)點最大，稱之為大頂堆（或大根堆）。堆的左右孩子沒有大小的順序。下面是一個小頂堆示例：

堆的存儲一般都用數(shù)組來存儲堆，i 節(jié)點的父節(jié)點下標就為(i–1)/2，它的左右子節(jié)點下標分別為2 ∗ i + 1 和 2 * i - 1，如第 0 個節(jié)點左右子節(jié)點下標分別為 1 和 2。

棧：

棧是一種線性表，只僅允許在表的一端進行插入和刪除操作，這一端被稱為棧頂（Top），相對地，把另一端稱為棧底（Bottom）。把新元素放到棧頂元素的上面，使之成為新的棧頂元素稱作進棧、入?；驂簵＃≒ush）；把棧頂元素刪除，使其相鄰的元素成為新的棧頂元素稱作出?；蛲藯＃≒op）。

文章參考：堆與棧的區(qū)別

5、線程調(diào)度的方式？

• 分時調(diào)度：所有線程輪流使用 CPU 的使用權(quán)，平均分配每個線程占用 CPU 的時間。
• '搶占式調(diào)度：優(yōu)先讓優(yōu)先級高的線程使用 CPU，如果線程的優(yōu)先級相同，那么會隨機選擇一個(線程隨機性)，Java使用的為搶占式調(diào)度。

線程的調(diào)度，取決于支持的是內(nèi)核級線程還是用戶級線程?

• 對于用戶級線程，內(nèi)核不知道線程的存在，就給了進程很大的自主權(quán)。內(nèi)核只是調(diào)度進程，由進程去選擇調(diào)度哪個線程來運行。
• 對于內(nèi)核級線程，線程的調(diào)度就交給了系統(tǒng)完成。

6、Linux 下如何查看文件前幾行和后幾行的命令？

這個是近期面試字節(jié)一面的時候，面試官問的問題：

# /etc/profile 的前10行內(nèi)容，應該是：
head -n 10 /etc/profile
# 查看/etc/profile 的最后5行內(nèi)容，應該是：
tail -n 5 /etc/profile
# 將內(nèi)容輸出到/home/test文件中
head -n 10 /etc/profile >> /home/test
tail -n 5 /etc/profile >> /home/test

7、TIME_WAIT為什么要等待2MSL，TIME_WAIT是客戶端狀態(tài)還是服務端狀態(tài)？

簡短概括：① 防止服務沒有收到客戶端發(fā)送的最后一個 ACK，則會重發(fā) FIN 請求，② 讓本次請求之前發(fā)送的請求都過期。

詳細介紹如下：

• 第一，保證客戶端發(fā)送的最后一個 ACK 報文能夠到達服務器，由于這個 ACK 報文可能丟失，站在服務器的角度看來，我已經(jīng)發(fā)送了 FIN+ACK 報文請求斷開了，客戶端還沒有給我回應，應該是我發(fā)送的請求斷開報文它沒有收到，于是服務器又會重新發(fā)送一次而客戶端就能在這個 2MSL 時間段內(nèi)收到這個重傳的報文，接著給出回應報文，并且會重啟 2MSL 計時器。
• 第二，防止 “已經(jīng)失效的連接請求報文段” 出現(xiàn)在本次請求中?？蛻舳税l(fā)送完最后一個確認報文后，在這個 2MSL 時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

8、為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？

為什么要三次握手？

• 簡短來說就是，在建立通信連接之前，通信雙方都確保自己與對方的發(fā)送、接收功能是正常的。

為什么要四次揮手？

通信雙方的任何一方都可以在數(shù)據(jù)傳輸結(jié)束之后，發(fā)出連接釋放的請求，待對方確認請求后進入半關(guān)閉狀態(tài)。當另一方也沒有數(shù)據(jù)再發(fā)送的時候，則發(fā)出連接釋放通知，對方確認后就完全關(guān)閉了 TCP 連接。

總結(jié)一句話：確保通信雙方在互相都關(guān)閉通信連接之前，已經(jīng)沒有數(shù)據(jù)在雙方之間繼續(xù)傳輸了，使雙方可以安全的關(guān)閉連接。

9、TCP 滑動窗口和流量控制機制？

TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。

接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

10、TCP 擁塞控制機制？

在某段時間，若對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。

為了進行擁塞控制，TCP 發(fā)送方要維持一個 擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。

TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網(wǎng)絡(luò)層也可以使路由器采用適當?shù)姆纸M丟棄策略（如主動隊列管理 AQM），以減少網(wǎng)絡(luò)擁塞的發(fā)生。

• 慢開始： 慢開始算法的思路是當主機開始發(fā)送數(shù)據(jù)時，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，那么可能會引起網(wǎng)絡(luò)阻塞，因為現(xiàn)在還不知道網(wǎng)絡(luò)的符合情況。經(jīng)驗表明，較好的方法是先探測一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd初始值為1，每經(jīng)過一個傳播輪次，cwnd加倍。
• 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經(jīng)過一個往返時間RTT就把發(fā)送放的cwnd加1.
• 快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復丟失的數(shù)據(jù)包。沒有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內(nèi)，沒有新的或復制的數(shù)據(jù)包被發(fā)送。有了 FRR，如果接收機接收到一個不按順序的數(shù)據(jù)段，它會立即給發(fā)送機發(fā)送一個重復確認。如果發(fā)送機接收到三個重復確認，它會假定確認件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 　當有單獨的數(shù)據(jù)包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數(shù)據(jù)信息包在某一段很短的時間內(nèi)丟失時，它則不能很有效地工作。

總結(jié)

本篇文章的內(nèi)容就到這了，希望大家可以多多關(guān)注腳本之家的其他精彩內(nèi)容！

最新評論