2021 10 月 AWS Interview 問題

# 2021 10 月 AWS Interview 問題 ## DNS TTL 長度優缺點 TTL 的全名叫做 Time to Live，是 DNS 解析的時候在使用的，主要的作用是設定每一筆紀錄在 DNS 快取伺服器所保留的時間我們常常在設定 DNS 紀錄的時候會有一個欄位叫做 TTL，到底要設定多少呢？這個值，如果你常常在變動 DNS 紀錄的話，有多小就調多小 (要看你的代管商最小能設定多少)，反之，如果你沒有常常變動，可以調大一點，單位是秒，若你設定 1800，表示 1800 秒。所以當你變更這筆 DNS 紀錄的時候，要 1800 秒後才會全球生效！ TTL - Is non-authoritative DNS servers will preserve information from this record within their resolver cache. (存留在快取伺服器的時間，假設在這個秒數的期間有人想要來詢問，伺服器就會回應）關於 TTL 的細節：https://haway.30cm.gg/what-is-ttl/ > 如果你需要時常變更 DNS 紀錄，則建議你 TTL 的時間可以設定 0 ~ 600 秒。如果是不常變更的話，則建議設定 1800 ~ 3600 秒。 ## tshark 的細節而跟圖形化介面的版本一樣，首先必須確認要收的是哪一張網卡的資料，所以我們先使用「tshark –D」這個指令，他會列出目前電腦的所有網卡。並且把檔案存成test.pcap。開始執行後，cmd會顯示你收的是哪個網路介面的封包，以及目前收到第幾個封包，而當你想要結束時，按下Ctrl+v就可以跳出。 [TCP Fundamentals Part 1 // TCP/IP Explained with Wireshark](https://www.youtube.com/watch?v=xdQ9sgpkrX8&t=9s) https://kknews.cc/zh-tw/code/rrkzgnn.html ![](https://i.imgur.com/4GVyvRF.png) TCP/IP 的網路層 — — IP 協定，不保證資料會照發送順序抵達接收端，接收端可利用表頭中的序列號 (Sequence Number, SEQ) 欄位進行排序、消除重複 (eliminate duplicates)，以保證資料接收的正確順序，並以位元組串流 (byte-stream) 的方式，傳遞給應用層。 TCP 使用確認號 (Acknowledgment Number) 欄位，指出下一個期望接收的序列號 (Sequence Number, SEQ)。 (表示編號小於此值的位元組，皆已正確接收) again: 序列號 (Sequence Number, SEQ)，並不是區段的 id 或編號 ! 它不代表一個唯一的區段，且不同於資料庫的主鍵，其值有可能重複。解包細節：https://www.itread01.com/content/1550149925.html ## HTTP 1.1 與 HTTP 2 的差別 ### HTTP/2 是 HTTP 的下一代規範，主要差異是在 HTTP 1.1 中，每個資源的請求都需使用單獨的 network thread 建立一個 TCP/IP 連線，但對瀏覽器來說同一時間每個網域所能發出的請求數是有限的，因此若請求資源過多就需等待先前的資源取得完畢，才能再發出請求，因此下載速度緩慢。在 HTTP/2 中，每個 TCP/IP 連線可請求多個資源，意即將資源分割成更小的 frame 來做請求和交錯傳輸，傳輸速度顯著提升。並且由於請求與回應標頭的壓縮、二進制封包結構、伺服器端推送和請求優先順序的排定，因此 HTTP/2 能提供更好的效能，可參考[這裡](https://tw.alphacamp.co/blog/2016-07-12-http2)。再從新的協議延伸至：TLS, SSL, HTTPS ### 什麼是 TLS, SSL, HTTPS? SSL 的全名是 Secure Sockets Layer，即安全通訊端層，簡而言之，這是一種標準的技術，用於保持網際網路連線安全以及防止在兩個系統之間發送的所有敏感資料被罪犯讀取及修改任何傳輸的資訊，包括潛在的個人詳細資料。兩個系統可以是伺服器與用戶端 (例如購物網站與瀏覽器)，或者伺服器至伺服器 (例如，含有個人身份資訊或含有薪資資訊的應用程式)。這樣做是為了確保使用者與網站、或兩個系統之間傳輸的任何資料保持無法被讀取的狀態。此技術可使用加密演算法以混淆輸送中的資料，防止駭客在資料透過連線發送時讀取資料。此資訊可能是任何敏感或個人資訊，包括信用卡號與其他財務資訊、姓名與地址。 TLS (Transport Layer Security，傳輸層安全性) 是更新、更安全的 SSL 版本。我們仍將安全性憑證稱為 SSL，因為這是較常用的詞彙，不過當您透過DigiCert購買 SSL 時，您所購買的其實是最新的 TLS 憑證及 ECC、RSA 或 DSA 的加密選項。 HTTPS (Hyper Text Transfer Protocol Secure，超級文字傳輸協議安全) 會在網站受到 SSL 憑證保護時在網址中出現。該憑證的詳細資料包括發行機構與網站擁有人的企業名稱，可以透過按一下瀏覽器列上的鎖定標記進行檢視。 ## 解析 request header 與 response header 細微 referrer 跟 content keep-alive 要再深入 * What is referrer? The Referer HTTP request header contains an absolute or partial address of the page that makes the request. The [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header allows a server to identify a page where people are visiting it from. This data can be used for analytics, logging, optimized caching, and more. * What is Content Keep-Alive https://byvoid.com/zht/blog/http-keep-alive-header/ * 什麼是Keep-Alive模式？我們知道HTTP協議採用“請求-應答”模式，當使用普通模式，即非KeepAlive模式時，每個請求/應答客戶和服務器都要新建一個連接，完成之後立即斷開連接（HTTP協議爲無連接的協議）；當使用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。 http 1.0中默認是關閉的，需要在http頭加入"Connection: Keep-Alive"，才能啓用Keep-Alive；http 1.1中默認啓用Keep-Alive，如果加入"Connection: close “，才關閉。目前大部分瀏覽器都是用http1.1協議，也就是說默認都會發起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep- Alive連接就看服務器設置情況 ![](https://i.imgur.com/sVA2CGu.png) *AWS 面試會問截圖資訊細節* TCP/IP 細節 https://notfalse.net/7/three-way-handshake ## Network troubleshooting skills in linux Packets don't lie ![](https://i.imgur.com/KUOQAqw.png) Layer 1 : The physical layer started Before you start checking cables, though, it’s a good idea to make sure that the interface isn’t just disabled. Issuing a command to bring the interface up can rule this problem out: ```bash= # ip link set eth0 up ``` Layer 2: Data Link Layer The most relevant Layer 2 protocol for most sysadmins is the Address Resolution Protocol (ARP), which maps Layer 3 IP addresses to Layer 2 Ethernet MAC addresses. A common problem you might encounter is an ARP entry that won’t populate, particularly for your host’s default gateway. If your localhost can’t successfully resolve its gateway’s Layer 2 MAC address, then it won’t be able to send any traffic to remote networks. This problem might be caused by having the wrong IP address configured for the gateway, or it may be another issue, such as a misconfigured switch port. We can check the entries in our ARP table with the ip neighbor command: ```bash= ip neighbor show ``` Layer 3: The network/internet layer While ping can be an easy way to tell if a host is alive and responding, it is by no means definitive. Many network operators block ICMP packets as a security precaution, although many others disagree with this practice. Another common gotcha is relying on the time field as an accurate indicator of network latency. ICMP packets can be rate limited by intermediate network gear, and they shouldn’t be relied upon to provide true representations of application latency. The next tool in the Layer 3 troubleshooting tool belt is the traceroute command. Traceroute takes advantage of the Time to Live (TTL) field in IP packets to determine the path that traffic takes to its destination. Traceroute will send out one packet at a time, beginning with a TTL of one. Since the packet expires in transit, the upstream router sends back an ICMP Time-to-Live Exceeded packet. Traceroute then increments the TTL to determine the next hop. The resulting output is a list of intermediate routers that a packet traversed on its way to the destination: 因為路徑會動態變化 Traffic may follow a different return path, and paths can change dynamically for many reasons. While traceroute may provide accurate path representations in small corporate networks, it often isn’t accurate when trying to trace across large networks or the internet. Notice that in the example above, the address for www.google.com resolved to 172.217.12.132. However, when we tried to ping the host, traffic was being sent to 1.2.3.4. Taking a look at the /etc/hosts file, we can see an override that someone must have carelessly added. Host file override issues are extremely common, especially if you work with application developers who often need to make these overrides to test their code during development. Layer 4: The transport layer The transport layer consists of the TCP and UDP protocols, with TCP being a connection-oriented protocol and UDP being connectionless. Applications listen on sockets, which consist of an IP address and a port. Traffic destined to an IP address on a specific port will be directed to the listening application by the kernel. A full discussion of these protocols is beyond the scope of this article, so we’ll focus on how to troubleshoot connectivity issues at these layers. The first thing that you may want to do is see what ports are listening on the localhost. The result can be useful if you can’t connect to a particular service on the machine, such as a web or SSH server. Another common issue occurs when a daemon or service won’t start because of something else listening on a port. The ss command is invaluable for performing these types of actions: ```bash ss -tunlp4 ``` -t - Show TCP ports. -u - Show UDP ports. -n - Do not try to resolve hostnames. -l - Show only listening ports. -p - Show the processes that are using a particular socket. -4 - Show only IPv4 sockets. The `telnet` command attempts to establish a TCP connection with whatever host and port you give it. This feature is perfect for testing remote TCP connectivity: ```bash= telnet database.example.com 3306 ``` Telnet works fine for TCP, but what about UDP? The netcat tool provides a simple way to check a remote UDP port: `nc 192.168.122.1 -u 80` test Ncat: Connection refused. or use `tcpdump` and `Wireshark` ## 最後一關可能問的問題四小時拉力賽- 你把 ELB、Route 53、ASG、WAF、VPN、Direct Connect 的東西可能看一下 Leadership