VUE項目打包后發布到Docker的Nginx服務器后，基本使用正常，發現前端有一個404錯誤，但頁面顯示正常，在退出登錄后，跳轉到404頁面，便這個404頁面是nginx缺省的，并不是自己vue項目的，參考網上資料后搞定了此問題，特此記錄：

一、原因

刷新頁面時訪問的資源在服務端找不到，因為vue-router設置的路徑不是真實存在的路徑。如上的404現象，是因為在nginx配置的根目錄/Data/app/xqsj_wx/dist下面壓根沒有loading這個真實資源存在，這些訪問資源都是在js里渲染的。
二、Dockerfile文件

注意打包文件拷貝的目標路徑，后面的default.conf要一致，否則會有問題

FROM urbgn6za.mirror.aliyuncs.com/library/nginx

MAINTAINER Wu Jize <wujize188@163.com>

RUN rm /etc/nginx/conf.d/default.conf

ADD default.conf /etc/nginx/conf.d/
#文件拷貝到鏡像的目標路徑，后面用$uri可以訪問到，
COPY dist/  /etc/nginx/html/

三、Nginx配置文件

Nginx啟動配置文件是default.conf文件，這個文件要特別注意格式

為一名web程序開發工程師，手上有幾個自己的站點，每天除了發布新的內容外，也會關注各自的流量變化，今日查看其中一個站點的時候，發現CNZZ統計過濾了大量PV，均來自于一個不屬于我的域名，于是將該域名放到站長工具檢測一看，好家伙，PR以及關鍵詞和我的一樣，于是訪問該域名查看源代碼仔細研究了一番，首先排除了采集的可能性，因為我全站都是絕對路徑，他的一點也沒改變，和我完全一樣。于是想到了惡意解析，翻閱了相關資料，都提到了這個原因，于是進入服務器配置一看，果不其然，沒有禁用默認的空主機頭，于是趕緊將其禁用，順便將此域名301跳轉到我的域名下面，以示“懲罰”，以下是我禁用空主機頭以及重定向的源碼

NameVirtualHost *

ServerAdmin xxx@xxx.com

DocumentRoot /404.html

ServerName www.惡意域名.com

ServerAlias 惡意域名.com

RedirectMatch permanent ^/(.*) http://www.我的域名.com/

配置完成后，重啟服務，訪問該惡意域名，順利跳轉至我的域名，大功告成！

很多建站新手，包括一些資深的研發人員把網站建設完成之后，在環境搭建的過程中可能沒有注意到，不同的服務商，可能給的基礎環境有所不同，大家拿到手之后要仔細檢查一下，惡意解析會帶來一系列的負面影響，首先是消耗你的服務器資源，占用服務器帶寬；其次是，一旦被工信部發現，這臺服務器上的域名都會受到影響，帶來很大損失。

TTP 基本概念

1. 什么是 HTTP？HTTP 的作用是什么？

HTTP 全稱：HyperText Transfer Protocol ，超文本傳輸協議。

HTTP 從客戶端到服務器端等一系列運作流程提供規范，是目前互聯網上使用的最廣泛的一種規范。

1. HTTP 協議用于客戶端和服務器端之間的通信
2. 通過請求和相應的交換達成通信
3. HTTP 是一種不保存狀態的協議
4. HTTP 通過使用 URI 來定位互聯網的資源

2. 什么是 TCP/IP？

1. 計算機與網絡設備通信，須基于一定的方法規范來進行。確定通信對象、通信語言選擇、開始結束通信方式、不同操作系統或者硬件之間如何通信，這些都是需要制定的規則協議。
2. TCP/IP 協議就是由這些多種互聯網通信相關協議組合而成，HTTP 為期子集。大部分常用的互聯網網絡，均通過 TCP/IP 協議族來進行。
3. TCP/IP 協議族常見的協議還包括：TCP、IP、HTTP、FDDI、FTP、DNS、UDP、SNMP 等。
4. TCP/IP 也是指 TCP 和 IP 這兩種協議，是在 IP 協議的通行過程中，使用到的協議族的統稱。

3. TCP/IP 協議族分幾層？

TCP/IP 協議族可以分為 4 層，分別是應用層、傳輸層、網絡層和鏈路層。

1. 應用層：應用服務之間的通信協議規范，如 FTP、DNS 和 HTTP 都在這層。

2. 傳輸層：傳輸層對應用層傳輸兩臺計算機之間的數據。傳輸層主要使用以下兩種協議：

• 傳輸控制協議 TCP（數據傳輸的單位是報文段）
• 用戶數據報協議 UDP（數據傳輸的單位是用戶數據報），不保證提供交付的可靠性。

3. 網絡層：網絡層對傳輸層提供的數據包進行傳送。用來處理網絡上流動的數據包，使用無連接的網際協議 IP 和許多種路由選擇協議。網絡層還有另一個任務就是選擇合適的路由。

4. 鏈路層（數據鏈路層）：硬件上的處理均在鏈路層的范圍內。如：操作系統、硬件設備的驅動、網卡等。

4. TCP/IP 協議族分層有什么優點？

TCP/IP 協議族分層的優點是：

1. 改動方便：如果僅使用一個協議，那么當其中的某一部分發生改變的時候，就需要把整體全部替換掉。
2. 設計簡單：使用分層時候，僅需要替換改變的層的內容，只需要把每層之間的接口部分定義規劃好，那么各層內部就可以隨意改變，更加靈活自由，在設計上也簡單很多。

5. TCP/IP 分層與 OSI 分層對比

TCP/IP 協議族按層次分為以下 4 層：應用層、傳輸層、網絡層和數據鏈路層。

OSI 則分為 7 層：應用層、表示層、會話層、運輸層、網絡層、數據鏈路層和物理層。

對應關系如下：

6. 什么是 TCP/IP 通信傳輸流？

通過 TCP/IP 協議通信方式，會遵循分層的順序與對方進行通信

• 發送端的順序是：應用層 -> 傳輸層 -> 網絡層 -> 鏈路層；
• 接受端的順序是：鏈路層 -> 網絡層 -> 傳輸層 -> 應用層。

7. TCP/IP 協議族中的 IP 協議

IP 網際協議處于網絡層，用于傳送數據包。它通過 IP 地址和 MAC 地址將數據包傳送到指定的位置。

其中 IP 地址指明了分配給節點的地址，可變化；MAC 地址指明了所屬網卡的固定地址，不可變化。

IP 之間的通信是依賴于 MAC 地址的，在網絡通信的過程中，根據 ARP （一種地址解析協議）協議，通過 IP 反查出對應 MAC 地址，再通過 MAC 地址來搜索中轉目標。

8. TCP/IP 協議族中的 TCP 協議是什么？

TCP 協議提供可靠的字節流服務，主要是通過采用三次握手的策略來確保傳輸數據的準確性的。

用 TCP 協議將數據包發送之后，它會向對方確認是否成功送達。握手過程中使用了 TCP 的標志（flag）——SYN（synchronize）和 ACK（acknowledgement）。

1. 發送端 A 發送 SYN 標志的數據包給信息接收方 B。
2. B 收到后數據包之后，回傳 SYN/ACK 標志的數據包，表示確認信息。
3. 發送端 A 再回傳一個 ACK 標志的數據包，代表“握手”結束。
4. 若在握手過程中某個階段莫名中斷，TCP 協議會再次按照相同順序發送相同的數據包。

9. 請介紹一下 TCP/IP 協議中的 DNS

DNS 全稱為 Domain Name System。

DNS 協議與 HTTP 一樣位于應用層，主要負責將域名和 IP 之間的相互解析。

10. IP、TCP、DNS 和 HTTP 的關系

11. URI 和 URL

1. URI （統一資源標識符）：用字符串標識互聯網上的某一資源。
2. URL （統一資源定位符）：表示網絡資源所在的位置。由上可見，URL 是 URI 的一個子集。

12. HTTP 向服務器傳遞信息的方法

方法名稱含義GET（獲取資源）請求訪問已被 URI 標識的資源。響應返回經服務器解析后的內容POST（傳輸實體主題）GET 和 POST 都可以傳輸實體的主題，但一般使用 POST 方法來傳輸。區別在意 POST 的主要目的并不是獲取響應的主體內容。PUT（傳輸文件）用來傳輸文件。將文件內容放到請求報文的主題之中，然后放到請求的 URI 中HEAD（獲得報文首部）HEAD 方法和 GET 方法一樣，但不返回報文主體的部分。用于確認 URI 是否有效及更新資源的時間等。DELETED（刪除文件）用來刪除文件，與 PUT 方法相反。DELETED 根據請求刪除 URI 內指定的資源OPTIONS（詢問支持的方法）查詢根據請求 URI 指定的資源支持方法TRACE（路徑追蹤）讓 Web 服務器端將之前的請求返回個客戶端的方法CONNECT（用隧道協議連接代理）與代理服務器通信時建立隧道，使用 SSL 和 TLS 協議把加密后的通信內容經網絡隧道進行傳輸。

13. 什么是持久連接？為什么要持久連接？

在使用 HTTP 協議建立通信之后，在沒有提出要斷開連接的時候，TCP 將一直保持連接狀態。

持久連接好處是減少了 TCP 連接的重復建立和斷開所造成的的額外開銷，減輕了服務器端的負載。而且減少重復建立連接的時間可以使 HTTP 請求和相應更早的結束，這樣 Web 頁面的加載速度也相應提高了。

14. Cookie 的作用是什么？它是怎樣工作的？

1. Cookie 技術將 Cookie 寫入請求信息和響應報文中，以此來控制和管理客戶端的狀態。
2. Cookie 是通過由服務器端發出響應報文中的 SetCookie 的首部字段的信息，告知客戶端需要保存 Cookie 的。當客戶端再次發送請求的時候，會在請求報文中加入 Cookie 值。服務器端在接收到帶有 Cookie 值的請求后，就會去查連接請求的來源，對比服務器存儲的記錄，然后得到之前的狀態信息。

15. 什么是 HTTP 報文？

HTTP 協議交互的信息被稱為 HTTP 報文。報文大致可以分為報文首部和報文主體兩塊，兩者由空行（CR+LF）來劃分，報文主體可以不要。

報文首部服務器端或者客戶端需要處理的請求或響應的內容及屬性空行（CR+LF）CR（回車）+ LF（換行）報文主體應被發送的數據（可以不要

1. 客戶端的 HTTP 報文被稱為請求報文

2. 服務器端的 HTTP 報文為響應報文

由上可知，請求報文和相應報文都是由請求行、狀態行、首部字段和其他組成。

16. HTTP 傳輸數據的方式有哪些？

• HTTP 可以直接按照數據的原貌進行傳輸，也可以在傳輸的過程中對數據進行編碼來提升傳輸的速率。但是在提高傳輸速率的同時，編碼操作會占用更多的 CPU 等資源。
• 可以采用壓縮傳輸內容的編碼方式提高傳送速率。采用將主題編碼分割成塊，然后進行編碼傳輸的分塊傳輸編碼形式，這種操作可以提高用戶的使用體驗。

注意：通常報文主體等同于實體主體。但是如果在傳輸的過程中進行編碼操作，實體主體的內容將發生變化，會導致它和報文主體產生差異。

17. 怎樣發送多種數據的多部分對象集合？

1. 在 HTTP 報文中使用多部分對象集合時，需要在首部字段里加上 Contenttype。
2. 通過字符串 boundary 來切分各類實體，這些實體是由多部分對象集合指定的。

18. 怎樣獲取部分內容的范圍請求？

可以通過首部字段 Range 來指定資源的 byte 的范圍。

1. 1001~2000 字節

?Range:bytes=1001-2000 

2. 1001 以后的所有字節

Range:bytes=1001- 

3. 從開始到 1000 字節和 2001~5000 的多重范圍

?Range:bytes=0-1000,2001-5000 

?針對范圍請求，響應會返回狀態碼為 206 的響應報文。而對于多重范圍的范圍請求，響應會在首部字段 ContentType 標明 multipart/byteranges 后返回響應報文。

19. 什么是內容協商？有哪些類型？

內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，然后提供給客戶端最為適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等作為判斷的基準。其內容包含在首部以下字段中：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。

內容協商包括：服務器驅動協商、客戶端驅動協商和透明協商三種。

1. 服務器驅動協商：由服務器端進行內容協商。以請求的首部字段為參考，在服務器端自動處理。但對用戶來說，以瀏覽器發送的信息作為判定的依據，并不一定能篩選出最優內容。
2. 客戶端缺東協商：?由客戶端進行內容協商的方式。用戶從瀏覽器顯示的可選項列表中手動選擇。還可以利用 JavaScript 腳本在 Web 頁面上自動進行上述選擇。比如按 OS 的類型或瀏覽器類型，自行切換成 PC 版頁面或手機版頁面。
3. 透明協商：是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

20. 基于 HTTP 的功能追加的協議有哪些？

1. 消除 HTTP 瓶頸的 SPDY 協議
2. 通過瀏覽器進行全雙工通信的 WebSocket
3. 成長了的 HTTP 2.0
4. Web 服務器管理文件的 WebDAV

21. 構建 Web 內容的技術有哪些？

1. HTML：Web 頁面幾乎都是由 HTML 寫成的。
2. 動態 HTML：是指使用客戶端腳本語言將靜態 HTML 變為動態的 HTML 的技術的總稱。例如：客戶端腳本語言 JavaScript 和指定于發生動態變化的 HTML 的 DOM 等。
3. Web 應用：如通過 Web 功能提供的應用程序；與 Web 服務器及程序協作的 CGI；因 Java 而普及的 Servletv 等。
4. 數據發布格式及語言：如可擴展標記語言 XML；發布更新信息的 RSS 和 Atom；JavaScript 衍生的輕量級易用 JSON 等。

22. HTTP 協議無狀態指什么？怎么才能將狀態保存？

HTTP 協議無狀態在一個會話里面，不同的兩次請求彼此是不了解。

但是通過 Cookie 或者 Session 可以將狀態保存，后續訪問可能利用到前面的信息。

23. GET 和 POST 的區別是什么？

1. 從服務器獲取信息一般使用 GET，想服務器發送信息一般用 POST。
2. GET 和 POST 數據提交方式不同，GET 通過在 URL 請求后面增加 filed=value 的封裝形式來進行；POST 則利用協議 BODY 來進行數據的封裝。
3. GET 傳輸數據量比較小，效率也不高；而 POST 可以傳輸比較大的數據量。
4. GET 不安全，可以被外部看見，造成信息泄露的風險，POST 相對來說安全一些。

24. HTTP 2.0 與 HTTP 1.1 的區別

1. HTTP 2.0 沒有采用文本格式，采用的是二進制格式。
2. HTTP 2.0 采用的是完全多路復用機制，而非有序并阻塞的。
3. HTTP 2.0 將報頭進行壓縮，降低了成本。
4. HTTP 2.0 服務器主動將響應“推送”到客戶端的緩存里面。

HTTP 狀態碼詳解

1. 什么是 HTTP 狀態碼？

HTTP 狀態碼全稱：HTTP Status Code。表示服務器在響應超文本傳輸協議訪問的時候返回的狀態 3 位數字代碼。例如，當客戶端向服務端進行 HTTP 請求的時候，服務器會返回一個代碼數據來回應請求，這個代碼數據就是: HTTP 狀態碼。

2. 請介紹一下常用的 HTTP 狀態碼？并解釋一下分別表示什么含義

1. 200：OK，基于 HTTP 協議的訪問在服務端被正常處理并返回。
2. 302：臨時重定向，表示請求的網頁臨時移動到其他的 URI。
3. 404：表示服務器上無法找到訪問的資料員。
4. 500：表明服務器端訪問響應發生了錯誤。可能是后臺 BUG，也可能是機器故障導致。

3. 狀態的主要類別有哪幾種？分別表示什么含義？

1. 1XX Informational（信息性狀態碼）： 服務器正在處理當前的請求。
2. 2XX Success（成功狀態碼）：請求被服務器正確接收，并正確執行。
3. 3XX Redirection（重定向狀態碼）：需要再次操作，才能完成整個訪問操作。
4. 4XX Client Error（客戶端錯誤狀態碼）：客戶端的請求出現問題，服務端無法響應（例如，訪問不存在的資源）。
5. 5XX Server Error（服務器錯誤狀態碼）：服務器內部處理訪問請求的時候出現異常。

HTTP 報文解析

1. HTTP 報文首部包含哪些內容？

HTTP 協議的請求和響應報文中必定包含 HTTP 首部。首部內容為客戶端和服務器分別處理請求和響應提供所需要的信息。

在請求中，HTTP 報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構成。

在響應中，HTTP 報文由 HTTP 版本、狀態碼（數字和原因短語）、HTTP 首部字段 3 部分構成。

2. 介紹一下 HTTP 首部字段，以及構成方式

首部字段的主要作用：給瀏覽器和服務器提供一些必要信息，如報文主體 SIZE、語言類型、認證方式等內容。它是 HTTP 報文的組成要素之一。

首部字段構成方式：由字段名稱和字段值組成，用冒號“:”分隔。例如：Content-type:text/html。首部字段可以有多個值組成。

3. 請介紹一下 HTTP 首部字段的類型有哪幾種

首部字段類型總共分為四類。如下所示：

1. 通用首部字段（General Header Fields）
2. 請求首部字段（Request Header Fields）
3. 響應首部字段（Response Header Fields）
4. 實體首部字段（Entity Header Fields）

3. HTTP 協議首部字段

通用首部字段
（請求報文與響應報文
都會使用的首部字段）Date創建報文時間Connection連接的管理Cache-Control緩存的控制Transfer-Encoding報文主體的傳輸編碼方式請求首部字段
（請求報文會使用的首部字段）Host請求資源所在服務器Accept可處理的媒體類型Accept-Charset可接收的字符集Accept-Encoding可接受的內容編碼Accept-Language可接受的自然語言響應首部字段
（響應報文會使用的首部字段）Accept-Ranges可接受的字節范圍Location令客戶端重新定向到的 URIServerHTTP 服務器的安裝信息實體首部字段
（請求報文與響應報文的實體
部分使用的首部字段）Allow資源可支持的 HTTP 方法Content-Type實體主類的類型Content-Encoding實體主體適用的編碼方式Content-Language實體主體的自然語言Content-Length實體主體的的字節數Content-Range實體主體的位置范圍，一般用于發出部分請求時使用

HTTPS 的使命

1. HTTP 的缺點及解決方案

缺點：

1. 明文形式通信（未進行加密操作），極可能被盜取數據。
2. 沒有驗證訪問者的合法身份，會遇到被偽裝欺騙可能。
3. 報文完整性無法進行驗證，所以內容信息會被篡改的可能。

解決方案：

1. 加密處理預防竊聽

• 通信加密：HTTP 協議加密機制缺失，但利用 SSL（SecureSocketLayer，安全套接層）或 TLS（TransportLayerSecurity，安全傳輸層協議）共同作用，加密 HTTP 的傳輸信息。

• 內容加密：HTTP 協議不提供加密操作，因此 HTTP 協議傳輸的數據本身加密，把 HTTP 報文里所含的數據進行加密操作。但數據傳輸的過程中仍有數據被篡改的可能。

2. 使用 SSL 可以驗證對方身份。SSL 除了具備加密處理能力，還使用了稱為證書的方法，可用于確定通信方。

3. 可以使用 MD5 和 SHA1 等散列值校驗的方法，以及用來確認文件的數字簽名方法。

非常可惜的是，以上的一些方法仍然存在很大的風險，如果想要有效地保證信息的安全性，則需要使用 HTTPS。

2. 什么是 HTTPS

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

1. HTTP 加上加密處理和認證以及完整性保護后即是 HTTPS

2. HTTPS 是身披 SSL 外殼的 HTTP

3. 什么是相互交換密鑰的公開密鑰加密技術

公開密鑰加密處理起來比共享密鑰加密方式更為復雜，因此若在通信時使用公開密鑰加密方式，效率就很低。

1. 使用公開密鑰加密方式，安全地交換在稍后的共享密鑰加密中要使用的密鑰

2. 確保交換的密鑰是安全的前提下，使用共享密鑰加密方式進行通信。

4. 請介紹一下 HTTPS 的安全通信機制

1. 利用對稱秘鑰原理，服務器端生成對稱秘鑰，私鑰自己保存，公鑰發送到外部。
2. 客戶端向一個權威的服務器檢查證書的合法性，如果合法，客戶端生成隨機數，這個數字就是通信的秘鑰，用公鑰加密這段隨機數，然后發送到服務器。
3. 服務器使用密鑰解密獲取對稱密鑰，然后，雙方就可以安全通信了。

5. HTTP 與 HTTPS 的區別是什么？

1. 安全性質不同：HTTP 是不安全的，而 HTTPS 是安全的。
2. URL 開頭不同：HTTP 以 http:// 開頭，HTTPS 以 https:// 開頭。
3. 標準端口不同：HTTP 標準端口是 80 ，HTTPS 的標準端口是 443。
4. 加密要求不同：HTTP 無需加密，而 HTTPS 對傳輸的數據進行加密。
5. 證書要求不同：HTTP 無需證書，而 HTTPS 需要 SSL 證書。

安全及漏洞全面解析

1. 什么是 SQL 注入？

SQL 注入是一種注入攻擊。攻擊者通過將破壞性 SQL 代碼進行數據庫查詢，使攻擊者能夠完全控制數據庫資源。

2. 如何防止 SQL 注入攻擊？

1. 不要使用動態 SQL，使用完整的語句和參數化方式來查詢。
2. 合理設置數據庫的權限。
3. 禁止直接向用戶顯示數據庫錯誤。
4. 對訪問數據庫的 Web 服務，使用 Web 應用程序防火墻。

3. 什么是 XSS？

XSS 全稱：跨站腳本攻擊（Cross Site Scripting）。是將前端腳本代碼插入 Web 頁面中，當用戶瀏覽頁面時，會執行嵌套在 Web 頁面里面的腳本代碼，從而達到攻擊用戶的目的。

XSS 類型包括：

• 存儲型 XSS：存入了數據庫，再取出來時導致的 XSS
• 反射型 XSS：在網址 URL 后輸入 XSS 代碼，如 <script> alert(1)</script>，然后訪問時導致 HTML 頁面加載這段代碼即可達到彈框效果。

4. 如何防止 XSS 漏洞

1. 在信息提交或者 url 參數傳遞前，對需要的參數進行過濾
2. 過濾用戶輸入，檢查用戶輸入的內容中是否有非法內容。如 <>（尖括號）、""（引號）、''（單引號）

5. 請介紹一下 CSRF 是什么？

CSRF：Cross-site request forgery 跨站請求偽造。

cookie 是網站利用來識別用戶的，用戶成功登陸之后瀏覽器就會得到一個 cookie 來標識其身份，在不關閉瀏覽器或者退出登錄，以后訪問這個網站會帶上這個 cookie。

1. 登錄某一受信任網站 X，并生成本地 Cookie。
2. 如果此時用戶也訪問了網站 B，訪問者在網站 A 的數據就會被 B 使用用戶 cookie 假冒更新。

6. CSRF 怎么防御？

1. 驗證碼與二次驗證
2. 對請求的 referer 進行檢測
3. 添加隨機 token 校驗