也祝愿大家拿到理想的offer！沖，功不唐捐，每一步的努力都算數(shù)。

服務(wù)器壓力測(cè)試

壓測(cè)服務(wù)器的方式

Webbench是常用的web 性能壓力測(cè)試工具。

• 測(cè)試處在相同硬件上，不同服務(wù)的性能以及不同硬件上同一個(gè)服務(wù)的運(yùn)行狀況。
• 展示服務(wù)器的兩項(xiàng)內(nèi)容：每秒鐘響應(yīng)請(qǐng)求數(shù)和每秒鐘傳輸數(shù)據(jù)量。

壓測(cè)基本原理

Webbench 首先 fork 出多個(gè)子進(jìn)程，每個(gè)子進(jìn)程都循環(huán)做 web 訪問(wèn)測(cè)試。子進(jìn)程把訪問(wèn)的結(jié)果通過(guò)pipe 告訴父進(jìn)程，父進(jìn)程做最終的統(tǒng)計(jì)結(jié)果。

壓測(cè)的瓶頸會(huì)在哪里

• io同步讀
• 存進(jìn)內(nèi)存
• 不同項(xiàng)目可能會(huì)有不同的點(diǎn)

怎么驗(yàn)證壓測(cè)瓶頸的猜測(cè)

查看系統(tǒng)參數(shù)

• 內(nèi)存
• cpu
• 文件描述符
• 磁盤io
• 看內(nèi)核態(tài)和用戶態(tài)占用的cpu比率
• 火焰圖

網(wǎng)絡(luò)相關(guān)的一些命令

• 查看端口狀態(tài)(netstat)
• 抓包(tcpdump)

http的問(wèn)題

http報(bào)文怎么檢測(cè)頭部和包體的間隔(兩個(gè)換行)

怎么檢測(cè)包體的結(jié)束(在頭部有一個(gè)content-length,然后你收內(nèi)容為這個(gè)長(zhǎng)度即可)

進(jìn)一步提升服務(wù)器性能的方向

高并發(fā)

• 線程->協(xié)程
• Nginx動(dòng)靜態(tài)分離

單個(gè)服務(wù)性能

• 多線程傳輸

實(shí)現(xiàn)原理

將源文件按長(zhǎng)度為分為N塊文件,然后開辟N個(gè)線程,每個(gè)線程傳輸一塊,最后合并所有線線程文件.比如
一個(gè)文件500M我們按長(zhǎng)度可以分5個(gè)線程傳輸.第一線程從0-100M,第二線程從100M-200M......最后合并5個(gè)線程文件.

實(shí)現(xiàn)流程

1.客戶端向服務(wù)端請(qǐng)求文件信息(名稱,長(zhǎng)度)
2.客戶端跟據(jù)文件長(zhǎng)度開辟N個(gè)線程連接服務(wù)端
3.服務(wù)端開辟新的線程與客戶端通信并傳輸文件
4.客戶端將每線程數(shù)據(jù)保存到一個(gè)文件
5.合并所有線程文件

各種模型的優(yōu)化方案

這里可能需要有一定理解和基礎(chǔ)才能看懂，看不懂就跳過(guò)就好了，未來(lái)就能看懂的嘿嘿。

同步寫非阻塞模型怎么優(yōu)化

異步寫非阻塞(aio_read)

proactor模式

靜態(tài)頁(yè)面動(dòng)態(tài)頁(yè)面分離

增加集群服務(wù)器(多進(jìn)程)

同步多線程和異步多線程區(qū)別

同步多線程的瓶頸

線程數(shù)

reactor模型是同步讀

異步多線程的缺點(diǎn)

異步導(dǎo)致邏輯復(fù)雜

需要考慮線程間同步互斥問(wèn)題。

各種模式的總結(jié)

1、同步單線程模式

優(yōu)點(diǎn)：a）實(shí)現(xiàn)簡(jiǎn)單。b）不用考慮線程間同步互斥問(wèn)題。

缺點(diǎn)：a）對(duì)CPU的使用率不高（容易在進(jìn)行IO操作或自身等待操作時(shí)阻塞），在多CPU時(shí)劣勢(shì)更明顯。b）并發(fā)性不好，在有的事件需要長(zhǎng)時(shí)間占用CPU處理的情況下，其他事件會(huì)長(zhǎng)時(shí)間等待得不到處理。

2、同步多線程模式

優(yōu)點(diǎn)：a）對(duì)CPU的使用率較高，在多CPU時(shí)優(yōu)勢(shì)更明顯。b）并發(fā)性好，各線程都能根據(jù)優(yōu)先級(jí)得到執(zhí)行。

缺點(diǎn)：a）需要考慮線程間同步互斥問(wèn)題。b）實(shí)現(xiàn)較復(fù)雜，不同線程的業(yè)務(wù)步驟有相互依賴時(shí)，需要分解實(shí)現(xiàn)成狀態(tài)機(jī)及事件通知驅(qū)動(dòng)模式（或者輪詢模式）。

3、異步多線程模式

優(yōu)點(diǎn)：a）對(duì)CPU的使用率高，在多CPU時(shí)優(yōu)勢(shì)更明顯。b）并發(fā)性好，各線程都能根據(jù)優(yōu)先級(jí)得到執(zhí)行。

缺點(diǎn)：a）需要考慮線程間同步互斥問(wèn)題。b）實(shí)現(xiàn)復(fù)雜，要把所有會(huì)導(dǎo)致阻塞的操作轉(zhuǎn)化為異步操作，另外不同線程的業(yè)務(wù)步驟有相互依賴時(shí)，需要分解實(shí)現(xiàn)成狀態(tài)機(jī)及事件通知驅(qū)動(dòng)模式（或者輪詢模式）。

4、異步單線程模式

優(yōu)點(diǎn)：a）對(duì)CPU的使用率高。b）不用考慮線程間同步互斥問(wèn)題。

缺點(diǎn)：a）實(shí)現(xiàn)較復(fù)雜，要把所有會(huì)導(dǎo)致阻塞的操作轉(zhuǎn)化為異步操作。b）并發(fā)性不好，在有的事件需要長(zhǎng)時(shí)間占用CPU處理的情況下，其他事件會(huì)長(zhǎng)時(shí)間等待得不到處理。c）在多CPU時(shí)不如多線程高效。

簡(jiǎn)單的說(shuō)：同步實(shí)現(xiàn)簡(jiǎn)單但是CPU利用率低，異步實(shí)現(xiàn)復(fù)雜但是CPU利用率高。

單線程不用考慮互斥但是并發(fā)性、多CPU利用率低，多線程需要考慮互斥但是并發(fā)性、多CPU利用率高。

綜合參考https://blog.csdn.net/weiganyi/article/details/11142763

當(dāng)下流行的技術(shù)架構(gòu)

使用多線程多進(jìn)程的服務(wù)器/常見服務(wù)器

• Apache：多進(jìn)程，核心模塊就叫做多路處理模塊(Multi-ProcessingModule，簡(jiǎn)稱MPM)。
• IIS：多進(jìn)程，應(yīng)用程序池。在Web園中你可以配置此應(yīng)用程序池所使用的最大工作進(jìn)程數(shù)。
• Nginx：多進(jìn)程+多路I/O復(fù)用+epoll。
• Tomcat：多線程
• Lighttpd：多線程

端口與連接相關(guān)問(wèn)題

可以多個(gè)線程監(jiān)聽同一個(gè)端口嗎

• 可以的，比如一個(gè)tcp一個(gè)udp
• 看5元組(服務(wù)器ip 服務(wù)器端口 協(xié)議 客戶端ip 客戶端端口)唯一確定一個(gè)連接
• 多個(gè)tcp多個(gè)udp監(jiān)聽同一個(gè)端口，accept會(huì)隨機(jī)返回
• 要打開端口復(fù)用

tcp/udp可以綁定同一個(gè)端口嗎(鏡像問(wèn)題)

tcp/udp均不可以兩個(gè)同類的監(jiān)聽socket綁定在同一個(gè)端口上。

但是可以一個(gè)tcp一個(gè)udp同時(shí)綁定一個(gè)端口。

由上述結(jié)果可知：TCP、UDP可以同時(shí)綁定一個(gè)端口8888，但是一個(gè)端口在同一時(shí)刻不可以被TCP或者UDP綁定2次。
原因如下：

1. tcp的端口不是物理概念，僅僅是協(xié)議棧中的兩個(gè)字節(jié)；
2. TCP和UDP的端口完全沒(méi)有任何關(guān)系，完全有可能又有一種XXP基于IP，也有端口的概念，這是完全可能的；
3. TCP和UDP傳輸協(xié)議監(jiān)聽同一個(gè)端口后，接收數(shù)據(jù)互不影響，不沖突。因?yàn)閿?shù)據(jù)接收時(shí)時(shí)根據(jù)五元組{傳輸協(xié)議，源IP，目的IP，源端口，目的端口}判斷接受者的。

端口復(fù)用的應(yīng)該僅在這些環(huán)境下使用

1、當(dāng)有一個(gè)有相同本地地址和端口的socket1處于TIME_WAIT狀態(tài)時(shí)，而你啟動(dòng)的程序的socket2要占用該地址和端口，你的程序就要用到該選項(xiàng)。

2、SO_REUSEADDR允許同一port上啟動(dòng)同一服務(wù)器的多個(gè)實(shí)例(多個(gè)進(jìn)程)。但每個(gè)實(shí)例綁定的IP地址是不能相同的。在有多塊網(wǎng)卡或用IP Alias技術(shù)的機(jī)器可以測(cè)試這種情況。

3、SO_REUSEADDR允許單個(gè)進(jìn)程綁定相同的端口到多個(gè)socket上，但每個(gè)socket綁定的ip地址不同。這和2很相似，區(qū)別請(qǐng)看UNPv1。

4、SO_REUSEADDR允許完全相同的地址和端口的重復(fù)綁定。但這只用于UDP的多播，不用于TCP。

需要注意的是，設(shè)置端口復(fù)用函數(shù)要在綁定之前調(diào)用，而且只要綁定到同一個(gè)端口的所有套接字都得設(shè)置復(fù)用：

socket連接的理解

如果一個(gè)程序創(chuàng)建了一個(gè)socket，并讓其監(jiān)聽80端口，其實(shí)是向TCP/IP協(xié)議棧聲明了其對(duì)80端口的占有。以后，所有目標(biāo)是80端口的TCP數(shù)據(jù)包都會(huì) 轉(zhuǎn)發(fā)給該程序（這里的程序，因?yàn)槭褂玫氖荢ocket編程接口，所以首先由Socket層來(lái)處理）。所謂accept函數(shù)，其實(shí)抽象的是TCP的連接建立過(guò)程。accept函數(shù)返回的新socket其實(shí)指代的是本次創(chuàng)建的連接，而一個(gè)連接是包括兩部分信息的，一個(gè)是源IP和源端口，另一個(gè)是宿IP和宿端口。所以，accept可以產(chǎn)生多個(gè)不同的socket，而這些socket里包含的宿IP和宿端口是不變的，變化的只是源IP和源端口。這樣的話，這些socket宿端口就可以都是80，而Socket層還是能根據(jù)源/宿對(duì)來(lái)準(zhǔn)確地分辨出IP包和socket的歸屬關(guān)系，從而完成對(duì)TCP/IP協(xié)議的操作封裝！而同時(shí)，放火墻的對(duì)IP包的處理規(guī)則也是清晰明了，不存在前面設(shè)想的種種復(fù)雜的情形。

多個(gè)服務(wù)器監(jiān)聽socket強(qiáng)行綁定到一個(gè)端口上，每次只能有一個(gè)accept得到正確的響應(yīng)。

明白socket只是對(duì)TCP/IP協(xié)議棧操作的抽象，而不是簡(jiǎn)單的映射關(guān)系，這很重要！

主機(jī)上最多能保持多少個(gè)連接

這個(gè)問(wèn)題在某乎上有一篇非常好的回答，不放鏈接了感興趣的同學(xué)自己去搜把。作者閃客sum。根據(jù)該回答個(gè)人歸納總結(jié)如下：

連接通過(guò)5元組唯一識(shí)別(源IP，源端口，目標(biāo)IP，目標(biāo)端口，協(xié)議)。協(xié)議比如tcp，udp。只要五元組不同就是不同的socket連接。

• 申請(qǐng)連接時(shí)，源IP源端口可以不指定。
  • 源IP操作系統(tǒng)根據(jù)網(wǎng)卡自動(dòng)選
    • 源端口自動(dòng)分配
    • 返回文件描述符用于通信

瓶頸1 端口號(hào)限制

[root]# cat /proc/sys/net/ipv4/ip_local_port_range 
1024 65000
//修改范圍
vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 60000 60009

理論端口號(hào)是16位，范圍1~65535，但實(shí)際上是有限制的，并不是所有端口號(hào)都可用。如果始終向同一目標(biāo)IP和同一目標(biāo)端口發(fā)出連接請(qǐng)求，首先會(huì)遇到的是端口號(hào)限制。

此時(shí)如果不斷更換目標(biāo)IP和目標(biāo)端口號(hào)，可以繼續(xù)發(fā)出連接請(qǐng)求

瓶頸2 文件描述符限制

linux對(duì)于文件描述符的限制有3個(gè)級(jí)別

• 系統(tǒng)級(jí)：當(dāng)前系統(tǒng)可打開的最大數(shù)量，通過(guò) cat /proc/sys/fs/file-max 查看
• 用戶級(jí)：指定用戶可打開的最大數(shù)量，通過(guò) cat /etc/security/limits.conf 查看
• 進(jìn)程級(jí)：?jiǎn)蝹€(gè)進(jìn)程可打開的最大數(shù)量，通過(guò) cat /proc/sys/fs/nr_open 查看

瓶頸3 線程并發(fā)過(guò)多

C10K問(wèn)題，當(dāng)服務(wù)器連接數(shù)達(dá)到1萬(wàn)且每個(gè)連接都需要消耗線程資源的時(shí)候，操作系統(tǒng)會(huì)忙于線程上下文切換，可能會(huì)導(dǎo)致系統(tǒng)崩潰，同時(shí)建立新連接會(huì)越來(lái)越慢。需要使用IO多路復(fù)用技術(shù)解決這一問(wèn)題。簡(jiǎn)而言之，使得一個(gè)線程可以管理多個(gè)TCP連接的資源。

瓶頸4 內(nèi)存

瓶頸5 CPU

一些其他問(wèn)題

跨域問(wèn)題

跨域問(wèn)題(https://blog.csdn.net/lianzhang861/article/details/84871369)

跨域，指的是瀏覽器不能執(zhí)行其他網(wǎng)站的腳本。它是由瀏覽器的同源策略造成的，是瀏覽器施加的安全限制。

所謂同源是指，域名，協(xié)議，端口均相同，只要有一個(gè)不同，就是跨域。不明白沒(méi)關(guān)系，舉個(gè)栗子：

http://www.123.com/index.html 調(diào)用 http://www.123.com/server.php （非跨域）

http://www.123.com/index.html 調(diào)用 http://www.456.com/server.php （主域名不同:123/456，跨域）

http://abc.123.com/index.html 調(diào)用 http://def.123.com/server.php （子域名不同:abc/def，跨域）

http://www.123.com:8080/index.html 調(diào)用 http://www.123.com:8081/server.php （端口不同:8080/8081，跨域）

http://www.123.com/index.html 調(diào)用 https://www.123.com/server.php （協(xié)議不同:http/https，跨域）

請(qǐng)注意：localhost和127.0.0.1雖然都指向本機(jī)，但也屬于跨域。

跨域會(huì)阻止什么操作？

瀏覽器是從兩個(gè)方面去做這個(gè)同源策略的，一是針對(duì)接口的請(qǐng)求，二是針對(duì)Dom的查詢

1.阻止接口請(qǐng)求比較好理解，比如用ajax從http://192.168.100.150:8020/實(shí)驗(yàn)/jsonp.html頁(yè)面向http://192.168.100.150:8081/zhxZone/webmana/dict/jsonp發(fā)起請(qǐng)求，由于兩個(gè)url端口不同，所以屬于跨域，在console打印臺(tái)會(huì)報(bào)No 'Access-Control-Allow-Origin' header is present on the requested resource

解決方案

2.后臺(tái)配置解決跨域

要說(shuō)前端解決跨域用jsonp最好，但我更喜歡通過(guò)配置后臺(tái)設(shè)置

同樣，因?yàn)槲矣玫膉ava，所有我只能列舉java的配置方法

我用的是 maven，spring mvc

首先在pom.xml中引入依賴

輸入一段url到看到頁(yè)面發(fā)生了什么(經(jīng)典問(wèn)題)

1、首先，在瀏覽器地址欄中輸入url

2、瀏覽器先查看瀏覽器緩存-系統(tǒng)緩存-路由器緩存，如果緩存中有，會(huì)直接在屏幕中顯示頁(yè)面內(nèi)容。若沒(méi)有，則跳到第三步操作。

• 瀏覽器緩存：瀏覽器會(huì)記錄DNS一段時(shí)間，因此，只是第一個(gè)地方解析DNS請(qǐng)求；
• 操作系統(tǒng)緩存：如果在瀏覽器緩存中不包含這個(gè)記錄，則會(huì)使系統(tǒng)調(diào)用操作系統(tǒng)，獲取操作系統(tǒng)的記錄(保存最近的DNS查詢緩存)；
• 路由器緩存：如果上述兩個(gè)步驟均不能成功獲取DNS記錄，繼續(xù)搜索路由器緩存；
• ISP緩存：若上述均失敗，繼續(xù)向ISP搜索。

3、在發(fā)送http請(qǐng)求前，需要域名解析(DNS解析)，解析獲取相應(yīng)的IP地址。

4、瀏覽器向服務(wù)器發(fā)起tcp連接，與瀏覽器建立tcp三次握手。

5、握手成功后，瀏覽器向服務(wù)器發(fā)送http請(qǐng)求，請(qǐng)求數(shù)據(jù)包。

6、服務(wù)器處理收到的請(qǐng)求，將數(shù)據(jù)返回至瀏覽器

7、瀏覽器收到HTTP響應(yīng)

8、讀取頁(yè)面內(nèi)容，瀏覽器渲染，解析html源碼

9、生成Dom樹、解析css樣式、js交互

10、客戶端和服務(wù)器交互

11、ajax查詢(javascript的內(nèi)容，了解即可)

epoll補(bǔ)充

EPOLLONESHOT事件(保證線程安全)

即使可以使用 ET 模式，一個(gè)socket 上的某個(gè)事件還是可能被觸發(fā)多次。這在并發(fā)程序中就會(huì)引起一個(gè) 問(wèn)題。比如一個(gè)線程在讀取完某個(gè) socket 上的數(shù)據(jù)后開始處理這些數(shù)據(jù)，而在數(shù)據(jù)的處理過(guò)程中該 socket 上又有新數(shù)據(jù)可讀（EPOLLIN 再次被觸發(fā)），此時(shí)另外一個(gè)線程被喚醒來(lái)讀取這些新的數(shù)據(jù)。于是就出現(xiàn)了兩個(gè)線程同時(shí)操作一個(gè) socket 的局面。一個(gè)socket連接在任一時(shí)刻都只被一個(gè)線程處理，可以使用 epoll 的 EPOLLONESHOT 事件實(shí)現(xiàn)。

對(duì)于注冊(cè)了 EPOLLONESHOT 事件的文件描述符，操作系統(tǒng)最多觸發(fā)其上注冊(cè)的一個(gè)可讀、可寫或者異常事件，且只觸發(fā)一次，除非我們使用 epoll_ctl 函數(shù)重置該文件描述符上注冊(cè)的 EPOLLONESHOT 事件。這樣，當(dāng)一個(gè)線程在處理某個(gè) socket 時(shí)，其他線程是不可能有機(jī)會(huì)操作該 socket 的。但反過(guò)來(lái)思考，注冊(cè)了 EPOLLONESHOT 事件的 socket 一旦被某個(gè)線程處理完畢， 該線程就應(yīng)該立即重置這個(gè) socket 上的 EPOLLONESHOT 事件，以確保這個(gè) socket 下一次可讀時(shí)，其 EPOLLIN 事件能被觸發(fā)，進(jìn)而讓其他工作線程有機(jī)會(huì)繼續(xù)處理這個(gè) socket。