Üstmetin transfer protokolü

Üstmetin transfer protokolü
Aile	İnternet protokolü ailesi
İşlev	köprü metni aktarımı
Son sürüm	3.0 (2018)
limanlar	80/TCP
Protokol yığınındaki konum
Uygulama HTTP Toplu taşıma TCP Ağ IP
standartlar
Orijinal HTTP (HTTP/0.9, 1991 ) RFC 1945 (HTTP/1.0, 1996 ) RFC 2616 (HTTP/1.1, 1999 ) RFC 2774 ( HTTP/1.2 [ alıntı gerekli ] , 2000 ) RFC 7230 , RFC 7231 , RFC 7232 , RFC 7233 , RFC 7234 , RFC 7235 (HTTP/1.1 revizyonu, 2014 ) RFC 7540 ( HTTP/2 , 2015 ) Köprü Metni Aktarım Protokolü Sürüm 3 ( HTTP/3 , 2018 ) ( İnternet Taslağı )

Köprü Metni Aktarım Protokolü ( İngilizce , Köprü Metni Aktarım Protokolü , kısaltılmış HTTP ), World Wide Web'deki dosyalar (XML, HTML ...) aracılığıyla bilgi aktarımına izin veren iletişim protokolüdür . 1999'da bir dizi RFC'nin yayınlanmasıyla sonuçlanan bir işbirliği olan World Wide Web Konsorsiyumu ve İnternet Mühendisliği Görev Gücü tarafından geliştirilmiştir ; bunlardan en önemlisi 1.1 sürümünü belirten RFC 2616'dır . HTTP, web mimarisinin yazılım öğeleri (istemciler, sunucular, proxy'ler ) tarafından iletişim kurmak için kullanılan sözdizimini ve semantiği tanımlar.

HTTP durum bilgisi olmayan bir protokoldür , bu nedenle önceki bağlantılarla ilgili hiçbir bilgiyi kaydetmez. Web uygulaması geliştirmenin sıklıkla durumunu koruması gerekir. Bunun için bir sunucunun istemci sisteminde saklayabileceği bilgiler olan çerezler kullanılır . Bu, web uygulamalarının bir oturum kavramını oluşturmasına ve ayrıca çerezler istemcide süresiz olarak saklanabileceğinden kullanıcıların izlenmesine olanak tanır .

Açıklama

İşlem odaklı bir protokoldür ve bir istemci ile bir sunucu arasındaki istek-yanıt şemasını takip eder. İstemci (genellikle " kullanıcı aracısı " olarak adlandırılır ), sunucuya belirli bir biçimde bir mesaj göndererek bir istekte bulunur. Sunucu (genellikle web sunucusu olarak adlandırılır) size bir yanıt mesajı gönderir. İstemci örnekleri, web tarayıcıları ve web örümcekleridir (İngilizce terimleri webcrawlers olarak da bilinir ).

Mesajlar

HTTP mesajları düz metindir , bu da onu daha okunabilir ve hata ayıklamayı kolaylaştırır. Ancak, bunun mesajları daha uzun yapma dezavantajı vardır. Mesajlar aşağıdaki yapıya sahiptir:

• İlk satır (satır başı ve satır besleme ile biter )
  • İstekler için: sunucunun gerektirdiği eylem ( istek yöntemi ), ardından kaynağın URL'si ve istemci tarafından desteklenen HTTP sürümü.
  • Yanıtlar için: Kullanılan HTTP'nin sürümü, ardından yanıt kodu (isteğe ne olduğunu ve ardından kaynağın URL'sini gösterir) ve söz konusu dönüşle ilişkili ifade.
• Boş bir satırla biten ileti başlıkları . Onlar meta verilerdir . Bu başlıklar protokole büyük esneklik sağlar.
• Mesaj gövdesi. İsteğe bağlı. Varlığı, mesajın önceki satırına ve URL'nin başvurduğu kaynağın türüne bağlıdır. Genellikle istemci ve sunucu arasında değiş tokuş edilen verilere sahiptir. Örneğin, bir istek için, işlenmek üzere sunucuya göndermek istediğiniz belirli verileri içerebilir. Bir yanıt için müşterinin talep ettiği verileri dahil edebilirsiniz.

İstek yöntemleri

telnet kullanan bir HTTP isteği . İstek , yanıt üstbilgileri ve yanıt gövdesi vurgulanır.

HTTP, kullanılabilecek önceden tanımlanmış bir dizi istek yöntemi (bazen "fiiller" olarak adlandırılır) tanımlar. Protokol, yeni yöntemler ekleme ve böylece yeni işlevler ekleme esnekliğine sahiptir. Sürümler ilerledikçe istek yöntemlerinin sayısı artmaktadır. Bu liste, WebDAV tarafından eklenen yöntemleri içerir .

Her yöntem, tanımlanan kaynak üzerinde gerçekleştirilmesini istediğiniz eylemi belirtir. Bu kaynağın temsil ettiği şey, sunucu uygulamasına bağlıdır. Örneğin, kaynak, sunucuda bulunan bir dosyaya karşılık gelebilir.

GET

GET yöntemi, belirtilen kaynağın bir temsilini ister. GET kullanan istekler yalnızca veri almalıdır ve başka bir etkisi olmamalıdır. (Bu, diğer bazı HTTP yöntemleri için de geçerlidir.)

BAŞLIK

RFC2616 . Bir GET isteğine karşılık gelen yanıtla aynı yanıtı ister, ancak yanıtta gövde döndürülmez. Bu, tüm içeriği taşımak zorunda kalmadan yanıt başlıklarından meta verileri alabilmek için kullanışlıdır.

POST

RFC2616 . İstek satırının URL'sinde tanımlanan kaynak tarafından işlenecek verileri gönderir. Veriler, talebin gövdesine dahil edilecektir. Anlamsal düzeyde, niteliği Content-Type başlığı tarafından belirlenecek olan yeni bir kaynak yaratmayı amaçlar . Örnekler:

• URL olarak kodlanmış form verileri için (URL'de değil, isteğin gövdesinde dolaşmasına rağmen): application/x-www-form-urlencoded
• Blokların tırmanması için, örn. dosyalar: multipart/form-data
• Yukarıdakilere ek olarak, zorunlu bir standart yoktur ve text/plain , application/json , application/octet-stream ,... gibi diğerleri de olabilir.

PUT

( RFC 2616 ) Sunucuya veri gönderir, ancak POST yönteminden farklı olarak, istek satırının URI'si onu işleyecek kaynağa atıfta bulunmaz, bunun yerine verinin kendisini tanımlar (RFC'deki ayrıntılı açıklamaya bakın ). POST ile olan diğer bir fark anlambilimdir (bkz. REST ): POST yeni içerik oluşturmaya yönelik iken, PUT daha çok onu güncellemeye yöneliktir (ancak onu da oluşturabilir).

Örnek:

PUT /yol/dosyaadı.html HTTP/1.1

SİL

RFC2616 . Belirtilen kaynağı siler.

İZLE

( RFC 2616 ) Bu yöntem, sunucudan istek mesajında ​​aldığı tüm verileri yanıta eklemesini ister. İstemci sunucuya ne geldiğini görebildiği ve bu şekilde ara sunucuların mesaja eklediği her şeyi görebildiği için hata ayıklama ve tanılama amacıyla kullanılır.

SEÇENEKLER

RFC2616 . Sunucunun belirli bir URL için desteklediği HTTP yöntemlerini döndürür. Bu, belirli bir kaynak yerine istek yoluyla bir web sunucusunun işlevselliğini kontrol etmek için kullanılabilir.

BAĞLAN

RFC2616 . Bir ana bilgisayara erişiminiz olup olmadığını bilmek için kullanılır, isteğin sunucuya ulaşması gerekmez, bu yöntem esas olarak bir proxy'nin bize şifreli çift yönlü veri "akışları" gibi özel koşullar altında bir ana bilgisayara erişim verip vermediğini bilmek için kullanılır. (SSL'nin gerektirdiği şekilde).

YAMA

( RFC 5789 ). İşlevi, bir kaynağın tamamen üzerine yazan PUT ile aynıdır. Bir veya daha fazla parçayı kısmen güncellemek için kullanılır. Ayrıca proxy ile kullanıma yöneliktir . ]

TAŞI

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

BİRLEŞTİR

RFC 3253

GÜNCELLEME

RFC 3253

ETİKET

RFC 3253

Yanıt kodları

Yanıt veya dönüş kodu, istekle ne olduğunu gösteren bir sayıdır. Yanıt içeriğinin geri kalanı bu kodun değerine bağlı olacaktır. Sistem esnektir ve aslında değişikliklere uyum sağlamak ve yeni durumları tanımlamak için kod listesi artmaktadır. Her kodun belirli bir anlamı vardır. Ancak, kodların sayısı, yüz veya daha fazlasına ait olup olmamasına bağlı olarak, sunucu tarafından verilen yanıtın türü tanımlanabilecek şekilde seçilir:

• 1xx biçim kodları: Bilgilendirici yanıtlar. İsteğin alındığını ve işlenmekte olduğunu gösterir.
• 2xx formatındaki kodlar: Doğru cevaplar. İsteğin doğru bir şekilde işlendiğini gösterir.
• 3xx biçimindeki kodlar: Yanıtları yeniden yönlendirin. İstemcinin isteği tamamlamak için daha fazla işlem yapması gerektiğini belirtir.
• 4xx formatındaki kodlar: İstemciden kaynaklanan hatalar. İstemci yanlış bir şey yaptığı için isteği işlerken bir hata olduğunu gösterir.
• 5xx biçim kodları: Sunucudan kaynaklanan hatalar. Bir sunucu hatası nedeniyle isteği işlerken bir hata olduğunu gösterir.

Başlıklar

Geçerli işlemle ilgili temel bilgileri sağlamak için HTTP isteklerinde veya yanıtlarında gönderilen meta verilerdir . Her başlık, bir başlık adı, ardından iki nokta üst üste, bir boşluk ve bu başlığın değeri, ardından bir satır başı ve ardından bir satır beslemesi ile belirtilir. Başlıkların sonunu belirtmek için boş bir satır kullanılır. Başlık yoksa boş satır kalmalıdır.

Başlıklar, tabanı değiştirmek zorunda kalmadan yeni işlevler eklemeye izin veren protokole büyük esneklik sağlar. Bu nedenle, HTTP sürümleri ortaya çıktıkça, daha fazla izin verilen başlık eklendi.

Başlıklar, istemci (örneğin, bir isteğe yanıt olarak içerdiği içeriğin türü belirtilebilir), sunucu (örneğin, talep ettiği içeriğin müşteri tarafından kabul edilebilir temsil türleri) tarafından işlenmesi gereken meta veriler içerebilir. aracılar (örneğin, proxy'ler tarafından önbelleğe alma nasıl yönetilir )

Bir başlığın girebileceği mesajın türüne bağlı olarak, bunları istek başlıkları, yanıt başlıkları ve hem istek hem de yanıtta gidebilen başlıklar olarak sınıflandırabiliriz.

Başlıkları işlevlerine göre sınıflandırabiliriz. Örneğin:

• Mesajı gönderen tarafından kabul edilen yetenekleri gösteren başlıklar: Kabul ( kabul edilen MIME'yi gösterir), Kabul-Charset (kabul edilen karakter kodunu gösterir), Kabul-Kodlama (kabul edilen sıkıştırma yöntemini gösterir), Kabul-Dil (kabul edileni gösterir ) dil), Kullanıcı Aracısı (istemciyi tanımlamak için), Sunucu (sunucunun türünü belirtir), İzin Ver (kaynak için izin verilen yöntemler)
• İçeriği tanımlayan başlıklar: Content-Type ( içeriğin MIME'sini gösterir ), Content-Length (mesajın uzunluğu), Content-Range , Content-Encoding , Content-Language , Content-Location .
• URI'lere atıfta bulunan başlıklar: Konum (içeriğin nerede olduğunu gösterir), Yönlendirici (isteğin kaynağını belirtir).
• Akış tasarrufu sağlayan başlıklar : Date (oluşturulma tarihi), If-Modified-Since , If-Unmodified-Since , If-Match , If-None-Match , If-Range , Expires , Last-Modified , Cache-Control , Via , Pragma , Etag , Yaş , Yeniden Dene-Sonra .
• Çerez kontrol başlıkları: Set-Cookie , Cookie
• Kimlik doğrulama için başlıklar: Yetkilendirme , WW-Authenticate
• İletişimi tanımlayan başlıklar: Ana bilgisayar (mesajın hedef makinesini belirtir), Bağlantı (bağlantının nasıl kurulacağını gösterir)
• Diğerleri: Aralık (yalnızca kaynağın bölümlerini indirmek için), Max-Forward (TRACE'e eklenen üstbilgilerin sınırı).

HTTP iletişim örneği

http://www.example.com/index.html URL'sine sahip bir kaynak almak için

1. www.example.com ana bilgisayarının 80 numaralı bağlantı noktasında bir bağlantı açılır . 80 numaralı bağlantı noktası, HTTP için varsayılan bağlantı noktasıdır. XXXX bağlantı noktasını kullanmak istiyorsanız, bunu URL'de http://www.example.com:XXXX/index.html biçiminde kodlamanız gerekir.
2. Aşağıdaki tarzda bir mesaj gönderilir:

/index.html HTTP/1.1'i ALIN
 Ev sahibi: www.example.com
 Referans: www.google.com
 Kullanıcı Aracısı: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
 Bağlantı: canlı tutmak
 [boş çizgi]

Sunucu yanıtı, bir web sayfası durumunda, istenen kaynak tarafından takip edilen başlıklardan oluşur:

HTTP/1.1 200 TAMAM
Tarih: 31 Aralık 2003 Cuma 23:59:59 GMT
İçerik Türü: metin/html
İçerik Uzunluğu: 1221

<html lang="eo">
<kafa>
<meta karakter kümesi="utf-8">
<title>Site başlığı</title>
</head>
<body>
<h1>Host ana sayfanız</h1>
(İçindekiler)
  .
  .
  .
</body>
</html>

Sürümler

HTTP, çoğu geriye dönük uyumlu olan protokolün birden çok sürümünden geçmiştir. RFC 2145 , HTTP sürüm numaralarının kullanımını açıklar. İstemci, isteğin başında sunucuya hangi sürümü kullandığını söyler ve sunucu yanıtında aynı veya daha eski bir sürümü kullanır.

0.9 (1991'de yayınlandı)

eski. Yalnızca bir komutu, GET'i destekler ve ayrıca HTTP sürüm numarasını belirtmez. Başlıkları desteklemez. Bu sürüm POST'u desteklemediğinden, istemci sunucuya fazla bilgi gönderemez.

HTTP/1.0 (Mayıs 1996)

Bu, iletişimde sürümünü belirten protokolün ilk revizyonudur ve özellikle proxy sunucularında hala yaygın olarak kullanılmaktadır. GET, HEAD ve POST istek yöntemlerine izin verir.

HTTP/1.1 (Haziran 1999) ]

Şu anda en çok kullanılan sürüm; ^{[ kaynak belirtilmeli ]} Kalıcı bağlantılar varsayılan olarak etkindir ve proxy'lerle sorunsuz çalışır . Ayrıca, müşterinin aynı bağlantı üzerinden aynı anda birden fazla istek göndermesine izin verir ( boru hattı ), bu da her istek için Gidiş-Dönüş gecikme süresini ortadan kaldırmayı mümkün kılar .

HTTP/1.2 (Şubat 2000)

PEP'in ilk 1995 taslakları - HTTP için Genişletme Mekanizması belgesi ( Protokol Uzatma Protokolünü önerir , kısaltılmış PEP), World Wide Web Konsorsiyumu tarafından yapılmış ve İnternet Mühendisliği Görev Gücü'ne sunulmuştur . PEP'in başlangıçta ayırt edici bir HTTP/1.2 aralığı olması amaçlandı. Ancak sonraki taslaklarda HTTP/1.2'ye yapılan atıf kaldırıldı. RFC 2774 ( deneysel), HTTP Uzantı Çerçevesi , yoğun olarak PEP içerir. Şubat 2000'de yayınlandı.

HTTP/2 (Mayıs 2015)

2012'de HTTP'nin ( HTTP/2 ) yeni sürümünün ilk taslakları ortaya çıktı. Bu yeni sürüm, http'nin uygulama semantiğini değiştirmez (tüm temel kavramlar değişmeden kalır). Geliştirmeleri, verilerin nasıl paketlendiğine ve taşınmasına odaklanır. Örneğin, tek bir bağlantı, başlık sıkıştırması veya 'sunucu gönderme' hizmeti kullanımını ekleyin. Başlıca tarayıcılar, yalnızca TLSv1.2 veya daha yüksek bir sürüm gerektiren ALPN uzantısını ]

HTTP/3 (Ekim 2018)

HTTP/3, temel aktarım protokolü için TCP yerine UDP kullanan, web'de halihazırda kullanımda olan HTTP/2'nin önerilen halefidir HTTP/2 gibi, protokolün önceki ana sürümlerinde kullanımdan kaldırılmamıştır. HTTP/3 desteği Cloudflare ve Google Chrome'a ​​Eylül 2019'da eklendi ​ ve kararlı Chrome ve Firefox sürümlerinde etkinleştirilebilir . ]

Ayrıca

• taşıma katmanı Güvenliği
• HTTPS
• HTTP Sıkı Aktarım Güvenliği
• HTTP (P2P)
• HTTP/2
• .har

Dış bağlantılar

• RFC-2616
• HTTP - Köprü Metni Aktarım Protokolü. W3C
• HTTP Gerçekten Kolaylaştı. James Marshall, 1997
• HTTP Başlıkları Doğrulaması Çevrimiçi URL Doğrulaması
• HTTP/2 Uyumluluk Testi