อยากสร้างเว็บที่รับโหลดได้เยอะ มีประสิทธิภาพสูง และจัดการกับ Request ได้แบบไหลลื่น ทำยังไงได้บ้าง ?
.
ต้องเจ้านี่ Nginx ซอฟต์แวร์ที่ช่วยจัดการ Request ต่าง ๆ ได้อย่างมีประสิทธิภาพ !! และวันนี้แอดจะพาเพื่อน ๆ มาทำความรู้จักกับเจ้านี่กันแบบคร่าว ๆ ว่ามันคืออะไร ทำงานยังไง หากพร้อมกันแล้ว ไปติดตามกันได้เลย 👇 😊
.
.
💡 รู้จัก Nginx
Nginx หรืออ่านว่า Engine-X เป็นเว็บเซิร์ฟเวอร์ที่สามารถรองรับผู้ใช้งานได้หลากหลาย และมีประสิทธิภาพสูง เป็น Open-Source รองรับ Reverse Proxying, Caching, Load Balancing สำหรับเซิร์ฟเวอร์ HTTP, TCP และ UDP, และการทำ Media Streaming นอกจากนี้ยังสามารถใช้เป็น Proxy Server สำหรับอีเมล์ (IMAP, POP3, and SMTP) ได้อีกด้วย
.
โดยส่วนใหญ่แล้วจะถูกใช้งานกับเว็บที่มีการอัพโหลด หรือ ดาวน์โหลดบ่อย ๆ หรือใช้ในการ Streaming สามารถรองรับการเชื่อมต่อในปริมาณมาก จัดการ Traffic ได้อย่างมีประสิทธิภาพและรวดเร็ว
.
.
⚙️ Nginx ทำงานยังไง ?
Nginx สร้างขึ้นเพื่อจัดการกับ Request ต่าง ๆ แบบ Asynchronous รับ Request พร้อมกันได้โดยไม่บล็อก Request อื่น ๆ โดยไม่เปลืองหน่วยความจำ กินทรัพยากรน้อย ทำให้ CPU และ RAM ทำงานได้มากยิ่งขึ้นนั่นเอง
.
ซึ่ง Nginx จะมีฟีเจอร์เด่น ๆ ดังนี้
🔹 Reverse proxy with caching
🔹 IPv6
🔹 Load balancing
🔹 FastCGI support with caching
🔹 WebSockets
🔹 Handling of static files, index files, and auto-indexing
🔹 TLS/SSL with SNI
.
NGINX จะถูกวางไว้ระหว่าง Clients และ Web Server เพื่อจัดการ SSL/TLS หรือใช้เพื่อเร่งความเร็วของเว็บ เป็นตัวกลางในการจัดการงานที่อาจจะทำให้เว็บเซิร์ฟเวอร์ของเราช้าลง เช่น Negotiating SSL/TLS, การบีบอัดและแคชเนื้อหาเพื่อปรับปรุงประสิทธิภาพ ซึ่งสามารถใช้กับเว็บที่สร้างขึ้นจากอะไรก็ได้ ไม่ว่าจะเป็น Node.js หรือ PHP ซึ่งส่วนใหญ่แล้วจะแคชเนื้อหาและ Reverse Proxy เพื่อลดภาระงานบนเซิร์ฟเวอร์ ใช้สามารถใช้ประโยชน์จากฮาร์ดแวร์ได้อย่างเต็มที่
.
.
✨ ข้อดี
🔸 มีความปลอดภัย รองรับมาตรฐาน HTTP/2
🔸 รองรับการทำงานของ HTTP
🔸 ประมวลผลได้รวดเร็ว
🔸 ทำงานแบบ Asynchronous รองรับ Request เยอะ ๆ ได้เป็นอย่างดี
.
.
⚠️ ข้อจำกัด
🔹 การ config ค่อนข้างซับซ้อน
🔹 ดูแลจัดการได้ยาก และไม่ค่อยมีความยืดหยุ่น
.
.
📑 อ่านข้อมูลเพิ่มเติมได้ที่นี่ : https://kinsta.com/knowledgebase/what-is-nginx/ , https://www.nginx.com/resources/glossary/nginx/
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#Nginx #BorntoDev
「tcp proxy」的推薦目錄:
- 關於tcp proxy 在 BorntoDev Facebook 的最佳貼文
- 關於tcp proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於tcp proxy 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於tcp proxy 在 Difference between HTTP(s) Reverse Proxy, TCP Proxy ... 的評價
- 關於tcp proxy 在 tcpproxy.py - An intercepting proxy for TCP data - GitHub 的評價
- 關於tcp proxy 在 The Top 61 Tcp Proxy Open Source Projects on Github 的評價
- 關於tcp proxy 在 Does HTTP proxy sends its own TCP packets or bypasses ... 的評價
- 關於tcp proxy 在 Developing a TCP Network Proxy - Pwn Adventure 3 - YouTube 的評價
- 關於tcp proxy 在 tcpprox - An intercepting TCP proxy - Staaldraad 的評價
tcp proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
ref: https://engineering.hellofresh.com/ambassador-the-evolution-of-ingress-gateway-at-hellofresh-3889232cab6f
本篇文章是 HelloFresh 這個美國生鮮食材訂購服務想要分享其團隊中 Ingress gateway 的演化史。該團隊過往使用 VM 作為其底層基礎架構來部署應用程式,後來遷移到
kubernetes 改用容器來部署,然而其內部的其他元件並沒有隨者 kubernetes 轉移而一併更新,譬如文章要探討的 Ingress gateway。
因此文章後將探討原先的 Ingress gateway 架構以及相關問題,最後如何將其與 kubernetes 進行整合來解決前述問題。
再使用 kubernetes 之前,團隊使用兩種不同的方式來處理,分別是內部 API Gateway Janus 以及網頁處理的 Entry (基於 Nginx 的 Reverse-Proxy)
團隊遷移到 kubernetes 之後,這兩個服務都想要透過 kubernetes Nginx Ingress 來處理,不過處理的過程中卻遇到一些問題。
1. 一致性: 每個微服務一開始都透過 Ingress 讓外界存取,然而當團隊開始使用 istio 後有些服務就改使用 Istio Ingress-Gateway 來處理,其他想要使用 TCP 的服務則會改使用 AWS ELB 來處理。
2. 延遲性: 因為 API Gateway 的存取節點都是基於 FQDN 的方式來存取,所以每個封包都要經過更多的節點來到達最終目的,這會增加整個封包傳輸時間。
最大的困惱還是第一個一致性的問題,k8s中有太多的方式讓外界可以存取期服務,每個都有自己獨特的設定,監控以及警示。
為了針對這些問題去解決,團隊內部先期構思一下到底什麼是團隊中理想的 Ingress Gateway
1. Reverse Proxy (HTTP) for websites
2. Mixture of an API Gateway
3. Kubernetes native
4. Advanced routing : (headers, methods, path)-based
5. JWT scope validation
6. Reliability features: Rate-limiting, Retries, Circuit breaking
7. Traffic shadowing
8. Interface for extensions
9. Integration with service mesh
後續文章包含了一些內容,如
1. 作者接者談談為什麼不使用 Service Mesh 所提供的 Ingress gateway
2. 到底要自行開發還是購買解決方案?(最後選擇了 Ambassador Edge Stack)
3. 如何透過 Ambassador Edge Stack 來解決團隊問題
4. 透過 Ambassador Edge Stack 後帶來的好處
有興趣的別忘了參閱全文
tcp proxy 在 矽谷牛的耕田筆記 Facebook 的最佳解答
最近跟大家分享一個 2020 年初左右的問題,這個問題的徵狀使用者透過 service 去存取相關服務時,會一直遲遲連接不上,直到 63 秒後服務才會通。
這個問題有兩種類型,一個是 63 秒後服務會通,一個則是 1 秒後會通,兩個背後的原因都一樣,這邊就來稍微簡介一下這個問題
# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network,最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊,至少要 1.16 以後,不過目前這個問題已經修復,所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新,目前該問題已經修復於大部分的 upstream
# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議,有一個已知的 bug 會使得其 checksum 發生錯誤,導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善,導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件,但是那些條件也剛好符合)
,最後導致封包的 checksum 不同,因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時,會不停地嘗試,每次失敗都會等待更多時間,分別是1,2,4,8,16,32秒
5. 五次都失敗後, TCP 就會觸發重傳機制,下一次的重傳就不會進入到第二次的 SNAT,因此封包就不會踩到問題,因此通過
# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到,也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化,其使用的 iptables 規則會避免二次 SNAT 的情況
# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋,都在探討 SNAT 後產生的 checksum,至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體,我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本,盼望從 Kernel 中來觀察並且理解這個問題,目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題
這個問題我認為非常有趣,也許自己的環境剛好沒有踩到,但是可以透過觀察不同的 issue 來研究各式各樣問題,也藉由這些過程來學習
相關 PR: https://github.com/kubernetes/kubernetes/pull/92035
tcp proxy 在 tcpproxy.py - An intercepting proxy for TCP data - GitHub 的推薦與評價
tcpproxy.py - An intercepting proxy for TCP data ... This tool opens a listening socket, receives data and then runs this data through a chain of proxy modules. ... <看更多>
tcp proxy 在 The Top 61 Tcp Proxy Open Source Projects on Github 的推薦與評價
Proxy is a high performance HTTP(S) proxies, SOCKS5 proxies,WEBSOCKET, TCP, UDP proxy server implemented by golang. Now, it supports chain-style proxies,nat ... ... <看更多>
tcp proxy 在 Difference between HTTP(s) Reverse Proxy, TCP Proxy ... 的推薦與評價
... <看更多>
相關內容