探索HTTP和HTTPS之間的主要差異，了解為什麼HTTPS對於一切都更快更好。 HTTP（超文本傳輸協議）是我們所知的網絡的協議基礎。 它位於TCP之上，TCP位於IP之上。 網頁可以使用HTTP或HTTPS（超文本傳輸協議安全版）。 它們有什麼不同？為什麼現在Chrome將HTTP標記為不安全呢？ 安全性 當您從服務器請求一個HTTP頁面時，數據會通過許多不同的網絡，每個網絡都由一個單獨的公司或實體控制。 從WiFi路由器開始，可能是咖啡店擁有的，也可能是城市公共網絡基礎設施擁有的，網絡中的每個節點都可以看到請求和響應，並以任何方式修改它。 它們可能會注入廣告，可能會注入惡意軟件，可能會記錄您輸入的任何憑據。中間的服務器可以充當中間人，發送被破壞的信息。 這也適用於任何未安全的Internet協議。 HTTPS流量是端到端加密的，這意味著在您和網絡另一端的服務器之間交換的信息中間沒有任何人可以閱讀。 端口 默認情況下，HTTP使用端口80提供服務，而HTTPS使用端口443提供服務。這些是默認端口，但Web服務器可以選擇在不同的隨機端口上提供內容，此時您需要在地址欄中指定： http://flaviocopes.com http://flaviocopes.com:80/javascript https://flaviocopes.com:8081/javascript HTTPS速度慢嗎？ 不是！相反地。 有一個關於頁面速度的神話。人們認為為了HTTPS所需要的TLS握手會使頁面速度變慢，但實際上，HTTPS頁面可以比HTTP頁面加載得更快。 為什麼？因為有了HTTP/2，HTTP協議的最新版本。HTTP/2可以並行提供請求，並要求建立安全連接，因此，如果您的服務器使用支持HTTP/2的現代Web服務器，那麼使用HTTPS時，您的網頁將會有顯著的速度提升。 HTTP/2引入了更好的並行處理、多路複用和壓縮，這是HTTP的一個很好的更新。 請參閱以下網頁的示例：<https://www.httpvshttps.com/>和<https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/> HTTPS是否會影響SEO？ 是的。 特別是，Google表示，HTTPS在SEO方面會給您帶來優勢。 此外，Google將會在其Chrome瀏覽器中正式將HTTP網站標記為不安全，這清楚地表明，如果您關心Google的需求並且想利用這一點，您應該盡快切換到HTTPS。最好的時間應該是3年前，下一個最好的時間就是今天。 實施HTTPS是否困難？ 一點也不。由於Let’s Encrypt提供免費的SSL證書，對HTTPS的推動產生了巨大的影響，現在每個體面的託管提供商都免費為所有帳戶實施它。多虧了這一點，在2018年HTTPS連接比HTTP連接更多。 在過去，對於一個普通網站來說，獲得SSL證書是一個高級選項，只有少數人願意為之支付費用，因為該網站不會賺錢或者不處理用戶數據。 如今已經沒有任何藉口了。

當資源需要傳輸時，快取是一種可以加快網絡連接速度的技術，因為傳輸的東西越少，效果就越好。 許多資源可能非常龐大，從時間和實際成本（例如在移動設備上）的角度來看都非常昂貴。 HTTP 提供了不同的快取策略，並由瀏覽器使用。 無快取 Expires 首部 條件式 GET 使用 If-Modified-Since 和 Last-Modified 使用 If-None-Match 和 ETag 無快取 首先，Cache-Control 首部可以告訴瀏覽器在檢查 ETag 值（稍後詳述）之前，永遠不要使用快取的資源，如下所示： Cache-Control: no-cache 更嚴格的 no-store 選項告訴瀏覽器（以及所有中介網路設備）不要將資源存儲在其快取中： Cache-Control: no-store 如果 Cache-Control 中含有 max-age 值，則此值用於確定該資源作為快取的有效時間（單位為秒）： Cache-Control: max-age=3600 Expires 首部 當發送 HTTP 請求時，瀏覽器會檢查其快取中是否有該頁面的副本，基於所請求的 URL。 如果有，則檢查該頁面的新鮮度。 如果HTTP 回應 Expires 首部（/http-response-headers/#expires）值小於當前日期和時間，則該頁面被認為是新鮮的。 Expires 首部的格式如下： Expires: Sat, 01 Dec 2018 16:00:00 GMT 條件式 GET 有不同的條件式 GET 方法。它們都基於使用 If-* 請求頭： 使用 If-Modified-Since 和 Last-Modified 使用 If-None-Match 和 ETag 使用 If-Modified-Since 和 Last-Modified 瀏覽器可以發送帶有 If-Modified-Since 首部的請求到服務器，該頭部基於當前快取頁面中獲取的 Last-Modified 首部值。...

每個 HTTP 回應都有一組標頭。這篇文章旨在列出所有這些標頭，並對它們進行描述。 每個 HTTP 回應都可以有一組標頭。 這篇文章旨在列出所有這些標頭，並對它們進行描述。 標準標頭 Accept-Patch Accept-Ranges Age Allow Alt-Svc Cache-Control Connection Content-Disposition Content-Encoding Content-Language Content-Length Content-Location Content-Range Content-Type Date Delta-Base ETag Expires IM Last-Modified Link Location Pragma Proxy-Authenticate Public-Key-Pins Retry-After Server Set-Cookie Strict-Transport-Security Trailer Transfer-Encoding Tk Upgrade Vary Via Warning WWW-Authenticate CORS 標頭 非標準標頭 Content-Security-Policy Refresh X-Powered-By X-Request-ID X-UA-Compatible X-XSS-Protection 標準標頭 Accept-Patch Accept-Patch: text/example;charset=utf-8 指定此服務器支援的修補文件格式。 Accept-Ranges Accept-Ranges: bytes 指示這個伺服器通過字節給服務支援哪些部分內容範圍類型。 Age Age: 12 對象在代理快取中的存放時間，以秒為單位。 Allow Allow: GET, HEAD...

HTTP（超文本傳輸協議）是 TCP/IP 應用協議之一，它是推動互聯網運作的各種協議套件之一。 讓我修改一下：它不僅僅是一個協議，而且是最成功和最受歡迎的協議。 HTTP 使 World Wide Web 運作，使瀏覽器能夠與托管網頁的遠程服務器進行通信。 HTTP 於 1991 年首次標準化，是因為 Tim Berners-Lee 自 1989 年起在歐洲核子研究中心（CERN）的工作。 當時的目標是讓研究人員可以輕鬆地交換和互相連接他們的論文。這是為了讓科學界更好地工作。 那個時候，Internet 主要應用基本上包括 FTP（文件傳輸協議）、電子郵件和新聞組（如今幾乎被廢棄）。 在 1993 年，第一個圖形化網頁瀏覽器 Mosaic 被發佈，從那時開始事情就一飛沖天。 網頁成為了互聯網的殺手應用。 隨著時間的推移，網頁和其周圍的生態系統發生了巨大變化，但基本原則仍然存在。一個進化的例子是：除了網頁之外，HTTP 現在還支持 REST API，這是一種通過 Internet 以編程方式訪問服務的常見方法。 HTTP 在 1997 年進行了一次小的修訂，推出了 HTTP/1.1，而在 2015 年，它的繼任者HTTP/2也被標準化，目前同時由全球各地的主要 Web 服務器所支持。 HTTP 協議被認為是不安全的，就像其他未在加密連接上提供的協議（如 SMTP、FTP）一樣。這就是為什麼現在大力推動使用 HTTPS（在 TLS 上運行的 HTTP）的原因。 也因此，HTTP/2 和 HTTPS 的構建模塊根植於 HTTP。在本文中，我將介紹 HTTP 的工作原理。 HTML 文件 HTTP 是像 Chrome、Firefox、Edge 和其他許多瀏覽器（也稱為客戶端）與 Web 服務器通信的方式。 超文本傳輸協議的名字源於傳輸的不僅僅是文件（如在 FTP - 文件傳輸協議 中），還有使用 HTML 編寫的超文本，並且由瀏覽器以漂亮的形式和互動鏈接表示。...

每個 HTTP 響應都附帶一個狀態碼，以明確的數字信息表明請求的處理方式。 HTTP 狀態碼是從服務器發送給客戶端的 HTTP 響應的首行。 如果您想知道服務器為什麼發送了特定的狀態碼以及它的含義，或者如果您正在構建服務器並且正在尋找要返回的完美的狀態碼，這個列表將非常有用。 狀態碼由 3 位數字和一個簡短的描述組成。 數字的第一位確定了響應組。 共有五個組： 1xx：信息性響應 - 表示請求已接收且已被理解 2xx：成功的響應 - 表示客戶端發出的請求已被接收、理解和接受 3xx：重定向 - 表示客戶端必須採取其他操作才能完成請求 4xx：客戶端錯誤 - 表示發生了客戶端引起的錯誤 5xx：服務器錯誤 - 表示發生了服務器上的錯誤 在本文的其餘部分中，我列出了所有有用的狀態碼。 （我刪除了一些特定於技術的狀態碼，例如 WebDAV 和很少使用的狀態碼） 信息性響應 狀態碼 描述 100 Continue 服務器已收到請求標頭，客戶端應繼續發送請求正文（例如，POST 請求）。 在請求被拒絕適用於不適當的標頭之後，將大的請求正文發送到服務器可能是低效的。 要求服務器檢查請求的標頭，客戶端必須在初始請求中作為標頭發送 Expect: 100-continue，並在接收到 100 Continue 狀態碼的響應後再發送正文。 如果客戶端收到 403（Forbidden）或 405（Method Not Allowed）等錯誤碼，那麼它就不應該發送請求的正文。 回應 417 Expectation Failed 表示應該重複請求，而不使用 Expect 標頭，因為它表示服務器不支持期望（對於 HTTP/1.0 服務器來說就是這種情況）。 101 Switching Protocols 客戶端要求服務器切換協議，服務器已同意切換。參見 RFC 7231 ＃6.2.2 成功的響應 狀態碼 描述 200 OK 標準的成功 HTTP 請求響應。 201 Created 通常是對 POST 請求的回應。請求已完成，並創建了新的資源。 202 Accepted 請求已被接受處理。對實際處理以及結果沒有具體要求，可能發生在另一個服務器上或批量處理。 203 Non-Authoritative Information 原始服務器返回了 200，並且位於客戶端和服務器之間的轉換代理更改了有效負載。 204 No Content 服務器成功處理了請求，但沒有返回任何內容。 205 Reset Content 服務器成功處理了請求，但沒有返回任何內容。類似於 204 響應，但服務器要求客戶端重置文檔視圖（例如用於清除表單） 206 Partial Content 根據客戶端發送的 Range 請求，服務器發送部分內容的響應。參見 RFC 7233 ＃4....

從開始到結束，當你在瀏覽器中輸入URL時會發生什麼事情 HTTP協議 我僅分析URL請求 與macOS / Linux相關的事情 DNS查找階段 gethostbyname TCP請求握手 發送請求 請求行 請求標頭 請求主體 響應 解析HTML 本文描述了瀏覽器如何使用HTTP/1.1協議進行頁面請求 如果你曾經參加過面試，可能會被問到：“當你在Google搜索框中輸入內容並按下Enter鍵時會發生什麼”. 這是一個最常問的問題之一。人們只是想看看你是否能解釋一些相當基本的概念，以及你是否對互聯網的工作原理有任何了解。 在這篇文章中，我將分析當你在瀏覽器的地址欄中輸入URL並按下Enter鍵時會發生什麼。 這是一個非常有趣的主題，我可以在單獨的文章中深入探討其中的許多技術。 這項技術很少更改，並且為人類所建造的最複雜和最廣泛的生態系統之一提供動力。 HTTP協議 首先，我特別提到HTTPS，因為使用HTTPS連接的情況有所不同。 我僅分析URL請求 現代瀏覽器具有知道你在地址欄中輸入的是實際URL還是搜索詞的能力，如果不是有效的URL，它們將使用默認搜索引擎。 我假設你輸入的是實際URL。 當你輸入URL並按下Enter鍵時，瀏覽器首先構建完整的URL。 如果你只輸入了一個域名，例如flaviocopes.com，瀏覽器默認會在前面添加 HTTP://，使用預設的HTTP協議。 與macOS / Linux相關的事情 只是提一下。Windows可能會略有不同。 DNS查找階段 瀏覽器開始進行DNS查找以獲取服務器的IP地址。 域名對於我們人類來說很方便，但互聯網根據IP地址對服務器的精確位置進行組織，IP地址是一組類似 222.324.3.1（IPv4）的數字。 首先，它檢查DNS本地緩存，看看域名最近是否已被解析。 Chrome有一個方便的DNS緩存可視化工具，你可以在chrome://net-internals/#dns查看。 如果在那裡找不到任何內容，瀏覽器將使用DNS解析器，使用gethostbyname POSIX系統調用檢索主機信息。 gethostbyname gethostbyname首先在本地主機文件中查找，該文件在macOS或Linux中位於/etc/hosts，以查看系統是否在本地提供該信息。 如果這沒有提供有關該域的任何信息，系統將向DNS服務器發送請求。 DNS服務器的地址存儲在系統首選項中。 下面是兩個常用的DNS服務器： 8.8.8.8：Google公共DNS服務器 1.1.1.1：CloudFlare DNS服務器 大多數人使用由其網絡提供商提供的DNS服務器。 瀏覽器使用UDP協議執行DNS請求。 TCP和UDP是計算機網絡的兩個基礎協議。它們處於相同的概念層級，但TCP是面向連接的協議，而UDP是無連接的協議，更加輕量級，用於以較小開銷發送消息。 如何進行UDP請求不在本教程的範圍內 DNS服務器可能在緩存中有域的IP。如果沒有，它將向樹狀DNS服務器發送請求。這是一個由13台實際服務器（分佈在全球各地）組成的系統，該系統驅動整個互聯網。 DNS服務器不知道地球上每個域名的地址。它只知道頂級DNS解析器的位置。頂級域是域名的擴展名：.com，.it，.pizza等。 一旦根DNS服務器收到請求，它會將請求轉發給頂級域（TLD）DNS服務器。假設你正在尋找flaviocopes.com，根域DNS服務器會返回.com TLD服務器的IP。 現在我們的DNS解析器將緩存該TLD服務器的IP，所以它不需要再次向根DNS服務器請求。 TLD DNS服務器將具有我們正在查找的域的權威名稱服務器的IP地址。 如何做到的？當你購買一個域名時，域名註冊商會向相應的TDL發送名稱服務器。當你更新名稱服務器（例如，當你更換主機提供商時），你的域名註冊商將自動更新此信息。 這些是主機提供商的DNS服務器。通常有不止1個，以作為備份。 例如： ns1.dreamhost.com ns2.dreamhost.com ns3.dreamhost.com DNS解析器從第一個開始，並嘗試查詢你正在查找的域名（包括子域名）的IP。 這是IP地址的終極真相來源。 現在我們有了IP地址，可以繼續我們的旅程。 TCP請求握手 有了服務器的IP地址後，瀏覽器現在可以與服務器建立TCP連接。...

每個 HTTP 請求都有一組必須和可選的標頭。本篇文章旨在列出所有這些標頭並對它們進行描述。 標準標頭 A-IM Accept Accept-Charset Accept-Encoding Accept-Language Accept-Datetime Access-Control-Request-Method Access-Control-Request-Headers Authorization Cache-Control Connection Content-Length Content-Type Cookie Date Expect Forwarded From Host If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since Max-Forwards Origin Pragma Proxy-Authorization Range Referer TE User-Agent Upgrade Via Warning 非標準標頭 Dnt X-Requested-With X-CSRF-Token 標準標頭 A-IM A-IM: feed 在響應中允許操作實例。在 RFC 3229 中定義。 Accept Accept: application/json 可接受的媒體類型/類型。 Accept-Charset Accept-Charset: utf-8 可接受的字符集。 Accept-Encoding Accept-Encoding: gzip, deflate 可接受的編碼列表。 Accept-Language Accept-Language: en-US 可接受的語言列表。 Accept-Datetime Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT...

詳細描述了HTTP/2協議的工作原理。 我建議先閱讀HTTP教程 HTTP/2是當前版本的HTTP協議。它由IETF（互聯網工程任務組）委員會於2015年發布，由於其獨特的功能，目前被廣泛采用。 HTTP/2比上一個版本的HTTP 1.1要更高效。在當時，HTTP/2的速度提升如此引人注目，以至於它很快就被廣泛采用。通過對Web服務器進行簡單的更改（因為HTTP/2與HTTP 1.1完全向下兼容），您的網站和Web應用程序現在自動運行得更快，這對用戶和SEO都有益處（因為速度是排名的關鍵因素）。 HTTP/2如何比HTTP/1.1更快？原因有很多，都是為了減少上一個版本的低效性，並引入能夠使瀏覽器更能快速提供資源的功能。 新版本協議的主要功能有： 請求和響應多路徑 HTTP標頭的高效壓縮 服務器推送 二進制通信 多路徑 在HTTP/2之前，每個TCP連接一次只能提供一個響應。 TCP是HTTP的底層協議。TCP位於傳輸層，而HTTP位於應用層。 HTTP/2在單個TCP連接上實現了請求/響應多路徑，允許服務器使用同一個連接提供多個請求，從而實現更快的通信。 這是一個對您的應用程序很有益的單一變化，使得一些優化技術變得過時，包括圖像合併（將多個圖像合併為一個，然後使用特殊的CSS技術進行“解多路”）和域名分片，另一種防止瀏覽器對同一域名的同時連接數量限制的技巧。 標頭壓縮 頁面和資源上的HTTP標頭可能會變得很大，考慮到正常使用Cookie和其他標頭值。壓縮使得HTTP的佔用空間更輕，減少了客戶端和服務器之間交換的數據量。 服務器推送 服務器推送是一種功能，允許將多個響應發送到單個請求。由於服務器知道在請求資源時，客戶端將要求其他補充資源（如CSS、JS、頁面上的圖像），因此服務器可以決定立即發送這些資源。 服務器可以還可以決定發送可能在未來請求中需要的資源，預先優化下一頁的加載並將其放在客戶端缓存中。 請注意，服務器推送也可能有一些缺點-例如，可能會向客戶端發送未必需要的過多數據（可能已在客戶端緩存中可用），因此需要謹慎使用。 二進制通信 HTTP/1.1使用基於文本的通信。HTTP/2使用二進制通信，這有一些優點，包括更容易解析、更少的錯誤以及更緊湊的格式。 未來的發展方向是什麼？ HTTP/3正在開發中，將從實驗性項目HTTP-over-QUIC進行調整。 QUIC是一種基於UDP（而不是TCP）的傳輸層協議，這意味著HTTP/3將基於與HTTP/2和HTTP/1.x完全不同的技術堆棧進行。

HTTPS協議是HTTP（超文本傳輸協議）的一個擴展，提供了安全的通信。 HTTP本身設計上存在不安全性。 當你在瀏覽器中打開並請求網頁時，你的數據需要經歷2次傳輸：一次從瀏覽器到網頁服務器，一次從網頁服務器到瀏覽器。 此外，根據網頁內容的不同，可能需要更多的連接來獲取CSS文件、JavaScript文件、圖片等等。 在這些連接中，你的數據可能會被任何網絡節點進行檢視和操控。 這可能帶來嚴重的後果：你的所有網絡活動可能被一個你甚至不知道其存在的第三方監視和記錄，一些網絡可能會注入廣告，而且你可能會成為中間人攻擊的目標，這是一種安全威脅，攻擊者可以操縱你的數據，甚至冒充你的計算機進行網絡操作。對於某個人來說，只要在公共的未加密的Wi-Fi網絡上聽取HTTP數據包是非常容易的。 HTTPS旨在從根本上解決這個問題：你的瀏覽器和網頁服務器之間的整個通信過程都是加密的。 隱私和安全是當今互聯網的一個重大關注點。幾年前，你可能只需要在登錄保護的頁面或電子商務結帳時使用加密連接。由於SSL證書的價格和複雜性，大多數網站僅使用HTTP。 而今天，任何網站都需要使用HTTPS。整個Web中超過50%的網站正在使用HTTPS。Google Chrome最近開始將HTTP網站標記為不安全，只為了給你一個強制在所有網站上強制使用HTTPS的合理理由。 使用HTTP時，默認的服務器端口是80，使用HTTPS時是443。如果服務器使用默認端口，則無需額外添加。 HTTPS有時也被稱為HTTP over SSL或HTTP over TLS。 兩者之間的區別很簡單：TLS是SSL的後繼者。 使用HTTPS時，唯一不加密的是網頁服務器的域名和服務器端口。 其他所有信息，包括資源路徑、標頭、Cookie和查詢參數都是加密的。 我不會詳細分析TLS協議的工作原理，但你可能認為它會增加相當多的開銷，你是對的。 在處理網絡資源時增加的任何計算都會給客戶端、服務器端和傳輸的數據包大小帶來開銷。 然而，HTTPS使得使用最新的協議HTTP/2成為可能，這相對於HTTP/1.1具有巨大的優勢：速度更快。 原因有很多，其中之一是標頭壓縮，另一個是資源多路徑。還有服務器推送功能，當請求某個資源時，服務器可以同時推送所需的所有資源（圖片、CSS、JS）。 除此之外，HTTP/2相對於HTTP/1.1有著更多的優點，前提是使用現代的設置進行合理配置，這使得HTTPS相對於HTTP來說速度更快。

為什麼面試程式設計職位的問題這麼難？ 我必須說，我討厭程式設計的面試問題。為什麼它們這麼難？ 如果你曾經使用過 HackerRank 之類的工具或讀過一本編程面試問題的書，你可能會同意我的看法。是的，整個行業都圍繞著編程面試和準備而存在。 我討厭那些面試問題。在網絡上，並不是每個人都同意我的觀點。似乎很多人想要繼續這種“傳統”。 幾年前，我決定不再從事合同工作/自由職業，並參與了許多不同公司的招聘過程。 在我意識到我基本上是不可雇用之前，這是另一個故事。我所指的不可雇用，是指我除了為自己建立自己的產品和資產，而不是為別人建造產品，無法為任何其他人工作。 我申請的公司中有大約一半的公司都有進行實踐性的“在家完成”項目的初步篩選。 沒人要求我實現FizzBuzz，或者其他經常被描述為“必須知識”的算法。 我們可能被誤導以為每一個招聘過程都像在 Google 那樣。我讀到有人花了一年準備 Google 的面試，結果申請時被拒絕了。可悲。 有無數的小型和中型公司從不使用嚴格而乏味的技術面試，以白板為基礎，涉及算法和數據結構等主題。没有 Google 和（噢！）Stack Overflow。 當然，了解這些主題是很不錯的，我認為你應該真正了解它們。 我也明白其中的思維：這些問題基本上都一樣，只是有 10-20 個變化。實現冒泡排序。好的，我能做到。他們只是想聽你在這個主題上的推理方式。你如何處理這個問題。但實際上，這只是解釋你記住了一個問題的內容。如果求職者是剛畢業的話，他們可能會記得得很清楚。如果求職者有 5 年的實際工作經驗，他們可能不會記得了。 FizzBuzz 更合理。它不是在學校教的，這個問題可以在 3 分鐘內解釋清楚，而且你可以對它進行推理。 但是如果我負責組織我公司的招聘，可能作為一個 CTO，我永遠不會讓一個人站在白板前，讓他們實現FizzBuzz。為什麼？首先，這完全沒有用 - 你將永遠不需要在現實世界中實現它。 其次，這給應聘者帶來了很大的壓力。很多人在這種情況下表現不佳，我也是其中之一。我可能只能展示出我價值的 10%，因為我無法在這樣對我來說陌生的環境下很好地發揮作用。 DHH（David Heinemeier Hansson，超受歡迎的 Ruby on Rails 框架的創建者）曾經說過: “我在白板上寫冒泡排序會失敗” 這太糟糕了，也許只能用來測試應聘者的神經。這完全不同於測試一個人對公司的價值，如如果我正在招聘一名程序員，進行編程等測試。 你在傳統的白板面試中能解決的任何問題都與程序員的實際工作沒有任何相關性。 我必須思考一下我上一次花時間決定要使用哪些算法，更不用說實現一個全新的算法了。那麼為什麼人們總是被問到這些問題呢？ 這是一個指出大公司也在朝著更好的方向發展的推文: 我們更新了發送給前端工程師候選人的內容，以更好地反映 Facebook 對這個職位的面試過程。我希望這能幫助人們準備他們的面試! pic.twitter.com/EvTyKbugYT — Dan Abramov (@dan_abramov) February 12, 2019 實際知識。向我們要求這個。 我記得在一次面試中我得到了一個很酷的問題：描述一下當你進行 Google 搜索時會發生什麼。這是一個開放式的問題，並且它是一個關於網絡協議和發生的細微差別的對話的開始。這是一個聰明的問題。 沒有白板，因為這是一個遠程的 Zoom 通話。 另一次面試是基於我在 React 上實現的編碼挑戰，離線完成的。我有 7 天的時間（實際編碼只需要 3 小時就夠了）。招聘過程的剩餘部分都基於我在這個代碼上所做的工作。...