mirror of
https://github.com/linkedin/school-of-sre
synced 2026-01-20 07:28:03 +00:00
Deployed d42a09c with MkDocs version: 1.1.2
This commit is contained in:
@@ -1059,7 +1059,7 @@
|
||||
|
||||
|
||||
<h1 id="dns">DNS</h1>
|
||||
<p>Domain Names are the simple human-readable names for websites. The Internet understands only IP addresses, but since memorizing incoherent numbers is not practical, domain names are used instead. These domain names are translated into IP addresses by the DNS infrastructure. When somebody tries to open www.linkedin.com in the browser, the browser tries to convert www.linkedin.com to an IP Address. This process is called DNS resolution. A simple pseudocode depicting this process looks this</p>
|
||||
<p>Domain Names are the simple human-readable names for websites. The Internet understands only IP addresses, but since memorizing incoherent numbers is not practical, domain names are used instead. These domain names are translated into IP addresses by the DNS infrastructure. When somebody tries to open <a href="www.linkedin.com">www.linkedin.com</a> in the browser, the browser tries to convert <a href="www.linkedin.com">www.linkedin.com</a> to an IP Address. This process is called DNS resolution. A simple pseudocode depicting this process looks this</p>
|
||||
<pre><code class="language-python">ip, err = getIPAddress(domainName)
|
||||
if err:
|
||||
print(“unknown Host Exception while trying to resolve:%s”.format(domainName))
|
||||
@@ -1076,7 +1076,7 @@ if err:
|
||||
else:
|
||||
return resp
|
||||
</code></pre>
|
||||
<p>Now lets understand what operating system kernel does when the gethostbyname function is called. The Linux operating system looks at the file <a href="https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html">/etc/nsswitch.conf</a> file which usually has a line</p>
|
||||
<p>Now lets understand what operating system kernel does when the <a href="https://man7.org/linux/man-pages/man3/gethostbyname.3.html">gethostbyname</a> function is called. The Linux operating system looks at the file <a href="https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html">/etc/nsswitch.conf</a> file which usually has a line</p>
|
||||
<pre><code class="language-bash">hosts: files dns
|
||||
</code></pre>
|
||||
<p>This line means the OS has to look up first in file (/etc/hosts) and then use DNS protocol to do the resolution if there is no match in /etc/hosts. </p>
|
||||
@@ -1098,7 +1098,7 @@ if err:
|
||||
|
||||
</code></pre>
|
||||
<p>As mentioned earlier, if no match exists in /etc/hosts, the OS tries to do a DNS resolution using the DNS protocol. The linux system makes a DNS request to the first IP in /etc/resolv.conf. If there is no response, requests are sent to subsequent servers in resolv.conf. These servers in resolv.conf are called DNS resolvers. The DNS resolvers are populated by <a href="https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol">DHCP</a> or statically configured by an administrator.
|
||||
<a href="https://linux.die.net/man/1/dig">Dig</a> is a userspace DNS system which creates and sends requests to DNS resolvers and prints the response it receives to the console.</p>
|
||||
<a href="https://linux.die.net/man/1/dig">Dig</a> is a userspace DNS system which creates and sends request to DNS resolvers and prints the response it receives to the console.</p>
|
||||
<pre><code class="language-bash">#run this command in one shell to capture all DNS requests
|
||||
sudo tcpdump -s 0 -A -i any port 53
|
||||
#make a dig request from another shell
|
||||
|
||||
@@ -1036,7 +1036,7 @@ curl linkedin.com -v
|
||||
* Connection #0 to host linkedin.com left intact
|
||||
* Closing connection 0
|
||||
</code></pre>
|
||||
<p>Here, in the first line GET is the verb, / is the path and 1.1 is the HTTP protocol version. Then there are key value pairs which give client capabilities and some details to the server. The server responds back with HTTP version, Status Code and Status message. Status codes 2xx means success, 3xx denotes redirection, 4xx denotes client side errors and 5xx server side errors.</p>
|
||||
<p>Here, in the first line GET is the verb, / is the path and 1.1 is the HTTP protocol version. Then there are key value pairs which give client capabilities and some details to the server. The server responds back with HTTP version, <a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes">Status Code and Status message</a>. Status codes 2xx means success, 3xx denotes redirection, 4xx denotes client side errors and 5xx server side errors.</p>
|
||||
<p>We will now jump in to see the difference between HTTP/1.0 and HTTP/1.1. </p>
|
||||
<pre><code class="language-bash">#On the terminal type
|
||||
telnet www.linkedin.com 80
|
||||
|
||||
@@ -1116,11 +1116,14 @@
|
||||
|
||||
<h1 id="linux-networking-fundamentals">Linux Networking Fundamentals</h1>
|
||||
<h2 id="prerequisites">Prerequisites</h2>
|
||||
<p>This course requires high-level knowledge of commonly used jargon in TCP/IP stack like DNS, TCP, UDP and HTTP. Basic familiarity with Linux jargon is sufficient to start this course. This course also expects basic exposure to Linux command-line tools. The course will require you to install certain utilities and run them as a part of the course exercises.</p>
|
||||
<ul>
|
||||
<li>High-level knowledge of commonly used jargon in TCP/IP stack like DNS, TCP, UDP and HTTP</li>
|
||||
<li><a href="https://linkedin.github.io/school-of-sre/linux_basics/command_line_basics/">Linux Commandline Basics</a></li>
|
||||
</ul>
|
||||
<h2 id="what-to-expect-from-this-course">What to expect from this course</h2>
|
||||
<p>Throughout the course, we cover how an SRE can optimize the system to improve their web stack performance and troubleshoot if there is an issue in any of the layers of the networking stack. This course tries to dig through each layer of traditional TCP/IP stack and expects an SRE to have a picture beyond the bird’s eye view of the functioning of the Internet.</p>
|
||||
<h2 id="what-is-not-covered-under-this-course">What is not covered under this course</h2>
|
||||
<p>This course spends time on the fundamentals. We are not covering concepts like HTTP/2.0, QUIC, TCP congestion control protocols, Anycast, BGP, CDN, Tunnels and Multicast. We expect that this course will provide the relevant basics to understand such concepts</p>
|
||||
<p>This course spends time on the fundamentals. We are not covering concepts like <a href="https://en.wikipedia.org/wiki/HTTP/2">HTTP/2.0</a>, <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>, <a href="https://en.wikipedia.org/wiki/TCP_congestion_control">TCP congestion control protocols</a>, <a href="https://en.wikipedia.org/wiki/Anycast">Anycast</a>, <a href="https://en.wikipedia.org/wiki/Border_Gateway_Protocol">BGP</a>, <a href="https://en.wikipedia.org/wiki/Content_delivery_network">CDN</a>, <a href="https://en.wikipedia.org/wiki/Virtual_private_network">Tunnels</a> and <a href="https://en.wikipedia.org/wiki/Multicast">Multicast</a>. We expect that this course will provide the relevant basics to understand such concepts</p>
|
||||
<h2 id="birds-eye-view-of-the-course">Birds eye view of the course</h2>
|
||||
<p>The course covers the question “What happens when you open linkedin.com in your browser?” The course follows the flow of TCP/IP stack.More specifically, the course covers topics of Application layer protocols DNS and HTTP, transport layer protocols UDP and TCP, networking layer protocol IP and Data Link Layer protocol </p>
|
||||
<h2 id="course-contents">Course Contents</h2>
|
||||
|
||||
File diff suppressed because one or more lines are too long
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
Reference in New Issue
Block a user