DEV Community

Cover image for URL'den Response'a: Tarayıcıda Ne Oluyor?
TAHA TÜZEL
TAHA TÜZEL

Posted on Fully Autonomous

URL'den Response'a: Tarayıcıda Ne Oluyor?

#webdev #beginners #software #learning

Her gün interneti kullanıyorum; bir siteye erişmek için adresi yazıp Enter'a basıyorum. Projelerde frontend tarafında fetch çağırıyorum, backend tarafında route tanımlıyorum. Bunlar sürekli kullandığım şeyler olsa da Browser ile Server arasında o kısa sürede tam olarak neler yaşandığı uzun süre benim için biraz ezberlenmiş bilgilerden ibaretti.

İzlediğim eğitim videolarının ve okuduğum blog yazılarının büyük bölümü benzer bir şablon üzerinden ilerliyordu:

DNS telefon rehberidir, IP bulunur, sayfa gelir.

Bu anlatım genel resmi anlamak için yeterli olsa da arka planda gerçekleşen süreci daha detaylı görmek istedim.

Bu nedenle teorik konuları çalışırken birkaç küçük lab yaptım; nslookup ve curl gibi araçlarla Request'in geçtiği adımları incelemeye çalıştım. Bu yazıda hem çalışma sırasında çıkardığım notları hem de kullandığım terminal komutlarını ve aldığım çıktıları tek bir akış altında topladım.

Büyük Resim: Request Nereden Geçiyor?

İlk olarak genel akışı oturtmak gerekiyor.

Browser'a bir adres yazıp Enter'a bastığımızda süreç kabaca şu sırayla ilerliyor:

  1. URL girilir
  2. DNS, domain adını IP adresine çevirir.
  3. TCP connection kurulur.
  4. HTTPS kullanılıyorsa TLS handshake gerçekleştirilir.
  5. Client, HTTP request gönderir.
  6. Server, HTTP response döndürür.
  7. Browser gelen içeriği işleyerek sayfayı render eder.

Kısaca:

URL → DNS → TCP → TLS → HTTP Request → HTTP Response → Render

Bu iletişimde temelde iki taraf bulunuyor.

Request'i başlatan taraf Client. Bu bir Browser, mobil uygulama veya terminalde kullandığımız curl olabilir.

Karşı tarafta ise Request'e Response üreten Server bulunuyor. Bu Server tarafında Nginx, Apache, Go veya Node.js ile çalışan bir servis olabilir.

Akış ilk bakışta oldukça basit görünüyor. Ancak her adımın içine girdiğimizde arka planda çok daha fazla mekanizmanın çalıştığını görüyoruz.

Adım 1: Yazdığımız URL Nelerden Oluşuyor?

Süreci anlamak için önce Browser'a yazdığımız URL'nin yapısına bakalım.

Örnek olarak biraz uzun bir URL'yi parçalarına ayıralım:

https://api.example.com:443/products/5?category=tech&sort=asc#reviews

https://   api.   example   .com   :443   /products/5   ?category=tech&sort=asc   #reviews
│          │      │         │      │      │             │                         │
Scheme     Sub-   Domain    TLD    Port   Path          Query Parameters          Fragment
           domain
Enter fullscreen mode Exit fullscreen mode

Buradaki her parçanın farklı bir görevi var:

  • Scheme (https): İletişimde hangi protocol'ün kullanılacağını belirtir.
  • Subdomain (api): Ana domain altında bulunan özelleşmiş servisi ifade eder. app, cdn veya api gibi yapılar burada karşımıza çıkar.
  • Domain (example): Ana domain adıdır.
  • TLD (.com): Top-Level Domain bölümüdür. .com, .org, .net, .dev gibi uzantılar bu gruba girer.
  • Port (:443): Server üzerinde hangi port'a bağlanılacağını belirtir. HTTP için varsayılan port 80, HTTPS için ise 443'tür. URL içerisinde açıkça yazılmasa bile Browser bunu bilir. Lokal geliştirmede kullandığımız localhost:3000 adresindeki 3000 de aynı kavramdır.
  • Path (/products/5): Server'dan istenen resource'un yolunu belirtir.
  • Query Parameters (?category=tech&sort=asc): Filtreleme veya sıralama gibi işlemler için kullanılan key-value çiftleridir.
  • Fragment (#reviews): Sayfa içerisindeki belirli bir bölümü ifade eder.

Burada diğer URL bileşenlerinden ayrılan kısım Fragment.

#reviews Server'a gönderilmez. Browser, sayfayı aldıktan sonra Fragment değerini Client tarafında kullanarak ilgili bölüme gider.

Yani URL'de gördüğümüz her bölüm HTTP Request'in bir parçası değildir.

Adım 2: DNS Sorgusu

URL'nin yapısından sonra sıradaki soru şu:

wikipedia.org yazdığımızda bilgisayar karşıdaki Server'ı nasıl buluyor?

Bilgisayarlar ve Router'lar bizim kullandığımız domain isimleri üzerinden iletişim kurmaz. Ağ üzerindeki cihazlara ulaşabilmek için IP adresleri kullanılır.

Bu nedenle Browser'ın wikipedia.org Server'ına ulaşabilmesi için önce bu domain'in arkasındaki IP adresini öğrenmesi gerekir.

Bu işlemi DNS — Domain Name System gerçekleştirir.

Browser bir IP adresini bulmaya çalışırken süreç kabaca şu şekilde ilerler:

  1. Önce kendi Cache'ini kontrol eder.
  2. Ardından işletim sisteminin Cache'ine ve yerel hosts dosyasına bakılır.
  3. Burada sonuç bulunamazsa bilgisayarın ağ ayarlarında tanımlanmış DNS Resolver kullanılır. Bu ISP'nin Resolver'ı olabileceği gibi 1.1.1.1 veya 8.8.8.8 gibi public DNS servisleri de olabilir.
  4. Resolver da cevabı bilmiyorsa Root DNS Server'lardan başlayarak ilgili TLD Server'a ve sonrasında domain'in Authoritative DNS Server'ına kadar uzanan sorgu süreci çalışır.

Burada önemli kavramlardan biri de TTL — Time To Live.

DNS record'larında bulunan TTL değeri saniye cinsinden tutulur ve DNS Response'unun Cache içerisinde ne kadar süre saklanabileceğini belirler.

Bunun pratikte önemli olduğu senaryolardan biri Server migration işlemidir.

Bir proje başka bir Server'a taşınıyor ve IP adresi değişiyorsa geçişten önce TTL değerinin düşürülmesi faydalı olabilir. Aksi durumda eski IP adresi bazı DNS Cache'lerinde kalmaya devam edebilir ve kullanıcıların bir bölümü eski Server'a yönlenebilir.

Terminal Denemesi: wikipedia.org IP Adresini Bulmak

DNS çözümlemesinin terminalde nasıl göründüğünü incelemek için PowerShell üzerinde nslookup kullanılabilir:

PS C:\> nslookup wikipedia.org
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    wikipedia.org
Addresses:  2a02:ec80:600:ed1a::1
          185.15.58.224
Enter fullscreen mode Exit fullscreen mode

Çıktıda birkaç önemli bilgi bulunuyor.

İlk olarak kullanılan DNS Resolver:

Server:  one.one.one.one
Address: 1.1.1.1
Enter fullscreen mode Exit fullscreen mode

Burada sorgu Cloudflare'ın 1.1.1.1 DNS Resolver'ına gönderiliyor.

Bir diğer önemli satır:

Non-authoritative answer
Enter fullscreen mode Exit fullscreen mode

1.1.1.1, Wikipedia'nın Authoritative DNS Server'ı değil. İlgili cevabı öğrenip Client'a ileten Resolver rolünde.

Response içerisinde iki farklı IP adresi de bulunuyor:

2a02:ec80:600:ed1a::1
185.15.58.224
Enter fullscreen mode Exit fullscreen mode

İlk adres IPv6 tarafındaki AAAA record, ikinci adres ise IPv4 tarafındaki A record.

Bu kayıt türlerini örnek bir site üzerinden inceleyelim:

  • A record: benimsitem.com adını doğrudan sunucunun IPv4 adresine bağlar.
  • AAAA record: A record'un IPv6 adresleri için kullanılan karşılığıdır.
  • CNAME record: www.benimsitem.com adını bir IP adresine değil, benimsitem.com adına bağlar.

Böylece biri www.benimsitem.com adresini yazdığında DNS önce benimsitem.com adını, ardından onun A kaydındaki IP adresini bulur. www için aynı IP adresini ikinci kez yazmam gerekmez. CNAME bir HTTP yönlendirmesi yapmaz; tarayıcıdaki URL değişmez.

DNS'e URL Verirsek Ne Oluyor?

nslookup ile şu sorguyu çalıştırdığımızı düşünelim:

PS C:\> nslookup http://http.badssl.com/
Server:  one.one.one.one
Address:  1.1.1.1

*** one.one.one.one can't find http://http.badssl.com/: Non-existent domain
Enter fullscreen mode Exit fullscreen mode

Buradaki problem DNS'e yalnızca domain vermek yerine bütün URL'nin gönderilmesi.

DNS'in görevi HTTP ile ilgilenmek değil; domain name resolution yapmaktır.

Bu nedenle http:// ve sondaki / domain'in bir parçası değildir.

Sadece hostname sorgulandığında sonuç alınabilir:

PS C:\> nslookup http.badssl.com
Non-authoritative answer:
Name:    http.badssl.com
Address:  104.154.89.105
Enter fullscreen mode Exit fullscreen mode

Bu küçük deney URL ile domain arasındaki farkı oldukça net gösteriyor.

Adım 3: TCP ve UDP

DNS üzerinden IP adresini bulduk.

Artık hangi Server'a ulaşmak istediğimiz belli. Sıradaki konu ise verinin iki cihaz arasında nasıl taşındığı.

Transport Layer'da en sık karşılaşılan iki protocol:

  • TCP
  • UDP

TCP: Reliable Connection

Web tarafında sık karşılaştığımız protocol'lerden biri TCP.

Bir HTML dosyasının, API Response'unun veya başka bir verinin yalnızca bir bölümünün ulaşması yeterli değildir. Gönderilen verinin eksiksiz ve doğru sırada karşı tarafa ulaşması gerekir.

TCP bunu sağlayabilmek için veri transferinden önce Client ve Server arasında bir Connection oluşturur.

Bu süreç 3-Way Handshake olarak adlandırılır:

sequenceDiagram
    autonumber
    participant C as Client (Sender)
    participant S as Server (Receiver)
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK

Akış şu şekilde ilerler:

  1. Client, Server'a SYN göndererek Connection başlatmak istediğini bildirir.
  2. Server, SYN-ACK ile cevap verir.
  3. Client, ACK gönderir ve Connection kurulmuş olur.

Connection kurulduktan sonra veri tek parça halinde gönderilmez. Büyük veri, ağ üzerinde taşınabilecek daha küçük bölümler halinde iletilir.

TCP burada sequence number kullanır.

Sequence number'lar Receiver'ın gelen verinin hangi sıraya ait olduğunu anlamasını sağlar. Böylece veri farklı zamanlarda ulaşsa bile doğru sıraya yerleştirilebilir.

Basitleştirilmiş olarak şöyle düşünebiliriz:

Sender

Data
 ↓
[1] [2] [3] [4] [5]
 ↓   ↓   ↓   ↓   ↓
Network
 ↓
Receiver
 ↓
[1] [2] [3] [4] [5]
 ↓
Original Data
Enter fullscreen mode Exit fullscreen mode

Network üzerinde her bölümün aynı anda veya aynı sırada ulaşması garanti değildir.

Örneğin veri şu şekilde ulaşabilir:

1 → 2 → 4 → 5
Enter fullscreen mode Exit fullscreen mode

Burada 3 numaralı bölüm eksik.

TCP'nin reliability mekanizmaları sayesinde eksik veri tespit edilir ve gerekli bölüm yeniden gönderilebilir.

1 → 2 → 4 → 5
        ↑
        3 missing

Sender
  ↓
retransmission
  ↓
3
Enter fullscreen mode Exit fullscreen mode

Bu sayede Receiver yalnızca gelen veriyi almakla kalmaz; eksik veya sırası bozulmuş veriyi de doğru şekilde işleyebilir.

REST API çağrıları, dosya indirme işlemleri veya database connection'ları gibi senaryolarda TCP kullanılmasının temel nedenlerinden biri bu reliability mekanizmasıdır.

UDP: Daha Hafif Bir Yaklaşım

UDP farklı bir çalışma modeline sahiptir.

TCP'deki gibi Connection kurulmaz ve 3-Way Handshake yapılmaz.

Packet gönderilir ancak karşı tarafa ulaşıp ulaşmadığına dair TCP seviyesinde bir garanti bulunmaz.

Packet kaybolduğunda otomatik retransmission garantisi de yoktur.

İlk bakışta bu bir dezavantaj gibi görünse de bazı kullanım alanlarında istenen davranış tam olarak budur.

Örneğin canlı yayın, online oyun veya görüntülü görüşme sırasında yarım saniye önce gönderilmiş bir Packet'ın tekrar ulaşması her zaman anlamlı olmayabilir. Güncel verinin düşük latency ile ulaşması daha önemli olabilir.

Bu nedenle bu tür senaryolarda UDP tercih edilebilir.

Adım 4: HTTP, HTTPS ve TLS

TCP Connection kurulduktan sonra HTTP Request gönderilebilir.

Burada HTTP ve HTTPS arasındaki farkı ayrı ele almak daha anlaşılır.

HTTP Request Gönderirsek Ne Oluyor?

HTTP tarafında Client ile Server arasındaki trafik TLS ile şifrelenmez.

Bu nedenle Request ve Response içerisinde taşınan bilgiler ağ üzerinde plaintext olarak görülebilir.

Örneğin:

GET /login HTTP/1.1
Host: example.com
Enter fullscreen mode Exit fullscreen mode

gibi bir Request HTTP üzerinden gönderildiğinde aradaki trafik şifreli değildir.

Bu yalnızca verinin okunabilmesi anlamına gelmez. HTTP trafiği aynı zamanda iletişim sırasında değiştirilmesine karşı da TLS seviyesinde bir koruma sağlamaz.

HTTPS kullanılmasının temel amacı burada ortaya çıkıyor.

HTTPS aslında tamamen farklı bir HTTP protocol'ü değil. Temelde:

HTTP
  +
TLS
  =
HTTPS
Enter fullscreen mode Exit fullscreen mode

şeklinde düşünülebilir.

TLS, HTTP iletişimine üç önemli özellik kazandırır:

  • Encryption: Client ile Server arasındaki trafiğin üçüncü kişiler tarafından okunmasını zorlaştırır.
  • Integrity: Trafiğin iletişim sırasında değiştirilip değiştirilmediğinin kontrol edilmesini sağlar.
  • Authentication: Client'ın gerçekten ulaşmak istediği Server ile iletişim kurduğunu doğrulamasına yardımcı olur.

Wikipedia'ya özellikle HTTP üzerinden bir Request gönderelim:

-I seçeneği GET yerine HEAD isteği gönderir; böylece yanıtın yalnızca durum satırını ve Header'larını görürüz.

PS C:\> curl.exe -I http://wikipedia.org
HTTP/1.1 301 Moved Permanently
content-length: 0
location: https://wikipedia.org/
server: HAProxy
x-cache: cp6014 int
x-cache-status: int-tls
connection: close
Enter fullscreen mode Exit fullscreen mode

Burada Wikipedia HTTP Request'i kabul edip sayfanın içeriğini göndermek yerine Client'ı HTTPS adresine yönlendiriyor.

Bunu Response'un ilk satırında görebiliyoruz:

HTTP/1.1 301 Moved Permanently
Enter fullscreen mode Exit fullscreen mode

301 Moved Permanently, istenen resource'un başka bir adrese taşındığını belirtiyor.

Nereye gidilmesi gerektiği ise Location Header içerisinde bulunuyor:

location: https://wikipedia.org/
Enter fullscreen mode Exit fullscreen mode

Akış kabaca şu hale geliyor:

Client
  │
  │ HTTP Request
  │ http://wikipedia.org
  ▼
Server
  │
  │ 301 Moved Permanently
  │ Location: https://wikipedia.org/
  ▼
Client
  │
  │ HTTPS Request
  ▼
Server
Enter fullscreen mode Exit fullscreen mode

Yani Browser'a http://wikipedia.org yazılmış olsa bile Server, Client'ı HTTPS endpoint'ine yönlendiriyor.

HTTPS Tarafında TLS Devreye Giriyor

HTTPS kullanıldığında HTTP iletişiminden önce TLS Handshake gerçekleşir.

HTTP Request henüz gönderilmeden önce Client ve Server güvenli iletişim için gerekli adımları tamamlar.

TLS'in ilk görevlerinden biri Client'ın bağlandığı Server'ın identity'sini doğrulamaktır.

Burada TLS Certificate devreye girer.

Server, TLS Handshake sırasında Client'a Certificate'ını gönderir.

Certificate içerisinde diğer bilgilerin yanında hangi domain veya domain'ler için geçerli olduğu bilgisi bulunur.

Client daha sonra kabaca şu kontrolleri yapar:

Server Certificate
        ↓
Certificate güvenilir bir CA tarafından imzalanmış mı?
        ↓
Certificate geçerlilik süresi içinde mi?
        ↓
Certificate bağlanılan domain için geçerli mi?
        ↓
Validation başarılı
Enter fullscreen mode Exit fullscreen mode

Buradaki CA — Certificate Authority, Certificate'ların güvenilirliğini doğrulayan yapılardır.

Browser ve işletim sistemleri önceden güvendikleri Root CA'ların listesini tutar. Server'ın gönderdiği Certificate'ın güven zinciri bu trusted root'lardan birine kadar doğrulanabiliyorsa Certificate güvenilir kabul edilebilir.

Domain kontrolü de bu sürecin önemli bir parçasıdır.

Örneğin Client:

https://www.wikipedia.org
Enter fullscreen mode Exit fullscreen mode

adresine bağlanıyorsa gelen Certificate'ın www.wikipedia.org için geçerli olup olmadığını kontrol eder.

Certificate, Server'ın public key'ini de içerir; eşleşen private key ise Client'a gönderilmez. Server, TLS Handshake sırasında private key'e sahip olduğunu dijital imzayla kanıtlar; Client bu imzayı public key ile doğrular. Böylece anahtar çifti Server'ın kimliğini doğrulamada kullanılır.

Client ve Server, Handshake sırasında ortak bir sır üzerinde anlaşarak simetrik session key'ler türetir. Sonraki HTTP iletişimi bu key'lerle şifrelenir; her Request public key ile ayrı ayrı şifrelenmez.

Basitleştirilmiş akış şu şekilde düşünülebilir:

Client
  │
  │ TCP Connection
  ▼
Server
  │
  │ TLS Handshake
  │ Certificate
  ▼
Client
  │
  │ Certificate Validation
  ▼
TLS Session Keys
  │
  ▼
Encrypted HTTP Request / Response
Enter fullscreen mode Exit fullscreen mode

Bu noktadan sonra network üzerinde taşınan HTTP içeriği doğrudan plaintext olarak görülmez.

Yani HTTPS yalnızca "HTTP'nin şifreli hali" demekten biraz daha fazlasını sağlar.

Client açısından iki önemli soru cevaplanmış olur:

Doğru Server ile mi konuşuyorum?
        ↓
Certificate Authentication

Aradaki trafik okunabilir veya değiştirilebilir mi?
        ↓
Encryption + Integrity
Enter fullscreen mode Exit fullscreen mode

Bu yapıdan sonra IP adresine doğrudan HTTPS Request gönderdiğimizde neden Certificate hatası aldığımızı inceleyebiliriz.

IP Adresine Doğrudan HTTPS Request Gönderirsek Ne Oluyor?

DNS sorgusundan Wikipedia'nın IP adreslerinden birini elde etmiştik:

185.15.58.224
Enter fullscreen mode Exit fullscreen mode

IP adresini bildiğimize göre doğrudan HTTPS Request göndermeyi deneyebiliriz:

PS C:\> curl.exe  https://185.15.58.224
Enter fullscreen mode Exit fullscreen mode

Ancak Request başarılı olmuyor:

curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - Hedef asıl adı yanlış.

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it.
Enter fullscreen mode Exit fullscreen mode

Burada problem TCP Connection'dan farklı bir katmanda oluşuyor.

IP adresine ulaşabiliyoruz ancak TLS Certificate doğrulaması başarısız oluyor.

Server tarafından kullanılan Certificate, wikipedia.org gibi domain isimleri için düzenlenmiş durumda.

Client ise şu adrese bağlanmaya çalışıyor:

https://185.15.58.224
Enter fullscreen mode Exit fullscreen mode

curl, Server'ın gönderdiği Certificate ile ulaşmaya çalıştığımız adresi karşılaştırıyor.

Certificate içerisindeki geçerli isimlerle IP adresi eşleşmediği için TLS doğrulaması başarısız oluyor ve HTTPS Connection devam etmiyor.

Aynı Request'i Domain ile Gönderirsek

Bu kez Request'i IP yerine domain üzerinden gönderelim:

PS C:\> curl.exe https://www.wikipedia.org
<!DOCTYPE html>
<html lang="en" class="no-js">
...
Enter fullscreen mode Exit fullscreen mode

Bu durumda TLS doğrulaması başarılı oluyor ve Response alınabiliyor.

Burada SNI — Server Name Indication da devreye giriyor.

TLS Handshake sırasında Client, hangi domain'e ulaşmak istediğini Server'a bildiriyor.

Basitleştirilmiş olarak:

Client
  │
  │ TLS Handshake
  │ SNI: www.wikipedia.org
  ▼
Server
  │
  │ Certificate for wikipedia.org
  ▼
Client
  │
  │ Certificate validation
  ▼
HTTPS Connection
Enter fullscreen mode Exit fullscreen mode

Böylece Server doğru Certificate'ı sunabiliyor ve Client Certificate doğrulamasını gerçekleştirebiliyor.

Burada DNS, TCP ve TLS'in farklı görevleri olduğu daha net görülüyor:

DNS
→ Hangi IP adresine gideceğiz?

TCP
→ Server ile reliable Connection nasıl kuracağız?

TLS
→ Bağlandığımız Server'ı nasıl doğrulayacağız ve trafiği nasıl şifreleyeceğiz?

HTTP
→ Hangi resource'u isteyeceğiz?
Enter fullscreen mode Exit fullscreen mode

Adım 5: Tek IP Adresinde Birden Fazla Site Nasıl Çalışıyor?

Tek bir IP adresi birden fazla web sitesine hizmet verebilir. HTTP/1.1 Request'indeki Host Header'ı, Server'ın hangi site için yanıt üreteceğini belirlemesine yardımcı olur. Bunu http.badssl.com için bulduğumuz 104.154.89.105 adresiyle üç şekilde inceleyelim.

Yalnızca IP Adresine Request

Önce Host değerini ayrıca belirtmeden IP adresine gidelim:

PS C:\> curl.exe 104.154.89.105
<title>Welcome to nginx!</title>
...
<h1>Welcome to nginx!</h1>
Enter fullscreen mode Exit fullscreen mode

Burada curl, URL'deki IP adresini Host değeri olarak kullanır. http.badssl.com istenmediği için BadSSL sayfası yerine Nginx'in karşılama sayfası döner.

IP Adresine Manuel Host Header ile Request

Şimdi aynı IP adresine bağlanıp hangi siteyi istediğimizi ayrıca belirtelim:

PS C:\> curl.exe 104.154.89.105 -H "Host: http.badssl.com"
<title>http.badssl.com</title>
...
<h1 style="font-size: 8vw;">http.badssl.com</h1>
Enter fullscreen mode Exit fullscreen mode

Ağdaki hedef hâlâ 104.154.89.105. Değişen şey HTTP Request'indeki Host: http.badssl.com başlığı. Server bu bilgiyi kullanarak BadSSL sayfasını döndürüyor. Bu, Virtual Host mantığını somutlaştırıyor.

URL ile Request ve curl -v Çıktısı

Son olarak IP yerine URL'yi kullanalım. -v seçeneği bağlantı bilgisini, giden Request'i ve gelen Response'u görmemizi sağlıyor. Ham çıktının ilgili satırları şöyle:

PS C:\> curl.exe -v http://http.badssl.com
* Host http.badssl.com:80 was resolved.
* IPv4: 104.154.89.105
*   Trying 104.154.89.105:80...
* Established connection to http.badssl.com (104.154.89.105 port 80) from 192.168.18.51 port 57300
> GET / HTTP/1.1
> Host: http.badssl.com
> User-Agent: curl/8.21.0
> Accept: */*
< HTTP/1.1 200 OK
< Server: nginx/1.10.3 (Ubuntu)
< Content-Type: text/html
< Content-Length: 483
< Cache-Control: no-store
<!DOCTYPE html>
...
<title>http.badssl.com</title>
Enter fullscreen mode Exit fullscreen mode

* ile başlayan satırlar adın IP adresine çözülmesini ve bağlantıyı gösteriyor. > işaretli satırlar giden HTTP Request'i: curl, URL'deki http.badssl.com adını alıp Host Header'ına otomatik eklemiş. < işaretli satırlar ise gelen Response'un status ve header bilgileri. 200 OK yanıtından sonra HTML içeriği geliyor.

Üç isteğin ulaştığı IP aynı; dönen sayfayı değiştiren, HTTP seviyesinde hangi host'un istendiği. DNS IP adresini bulurken Host Header'ı Server'ın doğru siteyi seçmesine yardımcı oluyor.

Adım 6: Gelen Yanıt Tarayıcıda Nasıl Görünüyor?

Şimdiye kadar Request'in Server'a ulaşmasını ve Response'un geri dönmesini inceledik. Peki Response Body içerisinde HTML geldiğinde Browser bunu nasıl gördüğümüz sayfaya dönüştürüyor?

Browser HTML'i okuyarak sayfanın yapısını temsil eden DOM'u oluşturur. HTML içinde bağlantısı verilen CSS, JavaScript ve görseller gibi dosyalar için de gerektiğinde yeni HTTP Request'ler gönderir. CSS kurallarını işleyip hangi öğelerin nasıl görüneceğini belirler; ardından öğelerin ekrandaki yerini hesaplar ve sayfayı çizer. JavaScript çalıştığında DOM'u değiştirebilir, yeni veriler isteyebilir ve sayfanın yeniden güncellenmesine yol açabilir.

Bu adımlar her zaman birbirini bekleyen tek bir sıra halinde gerçekleşmez. Browser, HTML'in tamamı gelmeden bazı kaynakları indirmeye ve sayfanın bir bölümünü göstermeye başlayabilir.

Terminalde kullandığımız curl ile Browser arasındaki fark da burada belirginleşir: curl bize Response'un içeriğini gösterir; Browser ise bu içeriği ve diğer kaynakları işleyerek ekranda gördüğümüz sayfayı oluşturur.

Kendime Notlar

Bu konuları çalışmadan önce networking tarafındaki birçok kavram birbirinden bağımsız başlıklar gibi görünüyordu.

DNS ayrı bir konu, TCP ayrı bir konu, TLS ayrı bir konu, HTTP ayrı bir konu.

Terminal üzerinde Request'in geçtiği adımları incelemeye başladığımda bunların aslında aynı iletişim sürecinin farklı aşamaları olduğu daha görünür hale geldi.

Frontend tarafında fetch() çağrısı yaparken veya backend tarafında bir route tanımlarken bütün bu katmanları sürekli düşünmek gerekmiyor.

Ancak Request beklediğimiz gibi çalışmadığında arka plandaki akışı bilmek problemin hangi noktada oluştuğunu anlamayı kolaylaştırıyor.

Bir HTTP Request artık yalnızca:

Client
  ↓
Server
Enter fullscreen mode Exit fullscreen mode

şeklinde düşünülmek zorunda değil.

Arka plandaki akış daha çok şu şekilde ilerliyor:

URL
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Response
 ↓
Browser'da işleme ve render
Enter fullscreen mode Exit fullscreen mode

Bu çalışmadan çıkan en faydalı alışkanlıklardan biri de şu oldu:

Bir Request beklediğim gibi çalışmadığında yalnızca Browser Console'a veya backend log'larına bakmak yerine terminal üzerinden Request'in kendisini de incelemek.

Top comments (1)

Collapse
 
dev_supports profile image
DEV SUPPORTS •

Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support

‍