Http ve https arasında performansta büyük farklılıklar var mı? HTTPS'nin HTTP kadar beşte bir olabileceğini okuduğumu hatırlıyorum. Bu, mevcut nesil web sunucuları / tarayıcıları için geçerli mi? Varsa, bunu destekleyecek teknik incelemeler var mı?

Bunun çok basit bir cevabı var: Kendi durumunuz için performans cezasının ne olduğunu görmek için web sunucunuzun performansını profilleyin. Bir HTTP vs HTTPS sunucusunun (JMeter ve Visual Studio akla geliyor) performansını karşılaştırmak için birkaç araç vardır ve kullanımı oldukça kolaydır.

Hiç kimse olmadan anlamlı bir cevap verebilir bazı web sitesinde, donanım, yazılım ve ağ yapılandırması doğası hakkında bilgi.

Diğerlerinin söylediği gibi, şifreleme nedeniyle bir miktar ek yük olacak, ancak oldukça bağımlıdır:

• Donanım
• Sunucu yazılımı
• Dinamik ve statik içeriğin oranı
• İstemcinin sunucuya uzaklığı
• Tipik oturum uzunluğu
• Vb (kişisel favorim)
• İstemcilerin önbellekleme davranışı

Deneyimlerime göre, dinamik içerik üzerinde ağır olan sunucular HTTPS'den daha az etkilenme eğilimindedir, çünkü şifreleme için harcanan zaman (SSL ek yükü) içerik oluşturma süresine kıyasla önemsizdir.

Bellekte kolayca önbelleğe alınabilen oldukça küçük bir dizi statik sayfa sunmaya ağır olan sunucular çok daha yüksek bir yükten muzdariptir (bir durumda, bir "intranet" üzerinde verim düşmüştür).

Düzenleme: Başkaları tarafından getirilen bir nokta, SSL el sıkışma HTTPS büyük maliyet olmasıdır. Bu doğrudur, bu nedenle "tipik oturum uzunluğu" ve "istemcilerin önbellekleme davranışı" önemlidir.

Çok, çok kısa seanslar, el sıkışma süresinin diğer performans faktörlerini zorlayacağı anlamına gelir. Daha uzun seanslar, el sıkışma maliyetinin seansın başlangıcında gerçekleşeceği, ancak sonraki taleplerin nispeten düşük genel masrafa sahip olacağı anlamına gelir.

İstemci önbelleğe alma, büyük ölçekli bir proxy sunucusundan tek tek tarayıcı önbelleğine kadar birçok adımda yapılabilir. Genellikle HTTPS içeriği paylaşılan bir önbellekte önbelleğe alınmaz (ancak birkaç proxy sunucusu bunu başarmak için ortadaki adam türü davranıştan yararlanabilir). Birçok tarayıcı HTTPS içeriğini geçerli oturum için ve çoğu zaman oturumlar arasında önbelleğe alır. Önbelleğe almama veya daha az önbelleğe almanın etkisi, istemcilerin aynı içeriği daha sık alacağı anlamına gelir. Bu, aynı sayıda kullanıcıya hizmet vermek için daha fazla istek ve bant genişliği ile sonuçlanır.

HTTPS, çok yavaş olabilen bir ilk el sıkışma gerektirir. El sıkışmasının bir parçası olarak aktarılan gerçek veri miktarı çok büyük değildir (tipik olarak 5 kB'ın altında), ancak çok küçük istekler için bu biraz ek yük olabilir. Ancak, el sıkışma yapıldıktan sonra, çok hızlı bir simetrik şifreleme biçimi kullanılır, bu nedenle havai yük minimumdur. Alt satır: HTTPS üzerinden çok sayıda kısa istekte bulunmak HTTP'den biraz daha yavaş olacaktır, ancak tek bir istekte çok fazla veri aktarırsanız, fark önemsiz olacaktır.

Ancak, keepalive HTTP / 1.1'deki varsayılan davranıştır, bu nedenle tek bir el sıkışma ve daha sonra aynı bağlantı üzerinden birçok istek yaparsınız . Bu HTTPS için önemli bir fark yaratır. Emin olmak için muhtemelen sitenizi (diğerlerinin önerdiği gibi) profil oluşturmalısınız, ancak performans farkının fark edilmeyeceğinden şüpheleniyorum.

HTTPS'nin gecikme sürenizi nasıl artıracağını gerçekten anlamak için HTTPS bağlantılarının nasıl kurulduğunu anlamanız gerekir. İşte güzel bir diyagram . Anahtar, müşterinin 2 "bacak" (bir gidiş-dönüş, bir istek gönderirseniz, sunucunun bir yanıt gönderir) sonra veri alması yerine, istemcinin en az 4 ayağa (2 gidiş-dönüş) kadar veri almamasıdır. . Dolayısıyla, bir paketin istemci ile sunucu arasında taşınması 100 ms sürüyorsa, ilk HTTPS isteğiniz en az 500 ms sürecektir.

Tabii ki, HTTPS bağlantısı (tarayıcıların yapması gereken) yeniden kullanılarak azaltılabilir, ancak bir HTTPS web sitesi yüklenirken bu ilk duraklamanın bir kısmını açıklar.

Ek yük şifreleme nedeniyle DEĞİLDİR. Modern bir CPU'da SSL için gerekli olan şifreleme önemsizdir.

Genel gider, bir HTTPS oturumu için gereken HTTP gezisi için gereken gidiş-dönüş sayısını uzun ve önemli ölçüde artıran SSL tokalaşmalarından kaynaklanmaktadır.

Sunucu simüle edilmiş yüksek gecikmeli bir bağlantının sonundayken sayfa yükleme sürelerini ölçün (Firebug gibi bir araç kullanarak). Yüksek gecikmeli bir bağlantıyı simüle etmek için araçlar mevcuttur - Linux için "netem" vardır. Aynı kurulumda HTTP'yi HTTPS ile karşılaştırın.

Gecikme bir dereceye kadar şu şekilde azaltılabilir:

• Sunucunuzun HTTP saklayıcılarını kullandığından emin olun - bu, istemcinin SSL oturumlarını yeniden kullanmasına olanak tanır ve başka bir el sıkışma ihtiyacını ortadan kaldırır
• Mümkün olduğunca kaynakları birleştirerek (örn. .Js dosyaları, CSS'yi içerir) ve istemci tarafı önbelleğe almayı teşvik ederek istek sayısını mümkün olduğunca az azaltma
• Sayfa yükleme sayısını azaltın, örneğin sayfaya gerekli olmayan verileri yükleyerek (belki de gizli bir HTML öğesinde) ve ardından istemci komut dosyasını kullanarak gösterin.

Aralık 2014 Güncellemesi

AnthumChris'in HTTP vs HTTPS Test web sitesini kullanarak kendi tarayıcınızda HTTP ve HTTPS performansı arasındaki farkı kolayca test edebilirsiniz : “Bu sayfa, güvenli olmayan HTTP ve şifreli HTTPS bağlantıları üzerindeki yükleme süresini ölçer. Her iki sayfa da 360 benzersiz, önbelleğe alınmamış resim yükler (toplamda 2,04 MB). ”

Sonuçlar sizi şaşırtabilir.

HTTPS performansı hakkında güncel bilgiye sahip olmak önemlidir, çünkü Let's Encrypt Sertifika Yetkilisi Mozilla, Akamai, Cisco, Electronic Frontier Foundation ve IdenTrust sayesinde 2015 Yazında ücretsiz, otomatik ve açık SSL sertifikaları vermeye başlayacak.

Haziran 2015 Güncellemesi

Let's Encrypt - Güncelleme Eylül 2015:

• Let's Encrypt Lansman Takvimi (16 Haz 2015)
• Kök ve Orta Düzey Sertifikaları Şifreleyelim (4 Haz 2015)
• Abonelik Sözleşmesini Şifreleyelim Taslağı (21 Mayıs 2015)

Twitter hakkında daha fazla bilgi: @letsencrypt

HTTPS ve SSL / TLS performansı hakkında daha fazla bilgi için bkz:

• TLS Hızlı mı?
• Yüksek Performanslı Tarayıcı Ağları, Bölüm 4: Aktarım Katmanı Güvenliği
• Hızaşırtma SSL
• SSL İşlemenin Anatomisi ve Performansı

HTTPS kullanmanın önemi hakkında daha fazla bilgi için bkz:

• Neden Her Şey İçin HTTPS? (Yalnızca HTTPS Standardı)
• Şifreleyelim (İnternet Güvenliği Araştırma Grubu)
• HTTPS Everywhere (Elektronik Sınır Vakfı)

Özetlemek gerekirse, İlya Grigorik'ten alıntı yapmama izin verin : "TLS'nin tek bir performans sorunu var: yeterince yaygın kullanılmıyor. Diğer her şey optimize edilebilir."

Aşağıdaki yorumlarından dolayı HTTP - HTTPS Test karşılaştırmasının yazarı olan Chris'e teşekkürler .

Mevcut üst yanıt tam olarak doğru değil.

Diğerlerinin de belirttiği gibi, https el sıkışma gerektirir ve bu nedenle daha fazla TCP / IP gidiş dönüşü yapar.

Bir WAN ortamında tipik olarak gecikme, sunucuda artan CPU kullanımı değil, sınırlayıcı faktör haline gelir.

Avrupa'dan ABD'ye gecikmenin 200 ms civarında olabileceğini aklınızda bulundurun (yolculuk süresi).

HTTPWatch ile bunu (tek kullanıcı durumu için) kolayca ölçebilirsiniz .

Şimdiye kadar bahsedilen her şeye ek olarak, bazı (tümü?) Web tarayıcılarının HTTPS üzerinden alınan önbelleğe alınmış içeriği güvenlik nedeniyle yerel sabit diskte saklamadığını lütfen unutmayın. Bu, kullanıcının çok fazla statik içeriğe sahip perspektif sayfalarında, tarayıcı yeniden başlatıldıktan sonra daha yavaş yüklendiği ve sunucunuzun perspektifinden, HTTPS üzerinden statik içerik için istek hacminin HTTP üzerinden olduğundan daha yüksek olacağı anlamına gelir.

Bunun tek bir cevabı yok.

Şifreleme her zaman daha fazla CPU tüketir. Bu, birçok durumda özel donanıma yüklenebilir ve maliyet, seçilen algoritmaya göre değişir. 3des, örneğin AES'den daha pahalıdır. Bazı algoritmalar şifreleyici için şifre çözücüden daha pahalıdır. Bazılarının tam tersi bir maliyeti vardır.

Toplu kriptodan daha pahalı el sıkışma maliyetidir. Yeni bağlantılar çok daha fazla CPU tüketecek. Bu, oturumun yeniden başlatılmasıyla, eski oturum sırlarının süresinin dolmasına kadar saklanması pahasına azaltılabilir. Bu, bir istemciden daha fazlası için geri dönmeyen küçük taleplerin en pahalı olduğu anlamına gelir.

İnternet arası trafik için, mevcut bant genişliği çok düşük olduğundan veri maliyetinizde bu maliyeti fark etmeyebilirsiniz. Ancak, yoğun bir sunucuda CPU kullanımında kesinlikle fark edeceksiniz.

(Bir çevirmeli kullanıcı olarak) SSL üzerinden aynı sayfanın normal HTTP'den birkaç kat daha yavaş olduğunu söyleyebilirim ...

Bazı durumlarda SSL el sıkışmalarının performans etkisi, SSL oturumunun her iki uçta (masaüstü ve sunucu) önbelleğe alınabilmesi ile azaltılacaktır. Örneğin Windows makinelerinde SSL oturumu 10 saate kadar önbelleğe alınabilir. Bkz. Http://support.microsoft.com/kb/247658/EN-US . Bazı SSL hızlandırıcılarında, oturumun önbelleğe alındığı zamanı ayarlamanıza olanak veren parametreler bulunur.

Dikkate alınması gereken diğer bir etki, HTTPS üzerinden sunulan statik içeriğin proxy'ler tarafından önbelleğe alınmayacağıdır ve bu, siteye aynı proxy üzerinden erişen birden fazla kullanıcının performansını düşürebilir. Bu, statik içeriğin masaüstlerinde de önbelleğe alınması gerçeğiyle hafifletilebilir, aksi belirtilmedikçe Internet Explorer sürüm 6 ve 7 önbelleğe alınabilir HTTPS statik içeriği (Araçlar Menüsü / Internet Seçenekleri / Gelişmiş / Güvenlik / Şifreli sayfaları kaydetme diske).

Küçük bir deney yaptım ve flickr'dan (233 kb) aynı görüntü için% 16 zaman farkı aldım:

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

Elbette bu sayılar bilgisayar performansı, bağlantı hızı, sunucu yükü, yolda QoS (tarayıcıdan sunucuya alınan belirli ağ yolu) gibi birçok faktöre bağlıdır, ancak genel fikri gösterir: HTTPS HTTP'den daha yavaştır, çünkü tamamlanması için daha fazla işlem gerektirir (SSL el sıkışma ve verileri kodlama / kod çözme).

İşte SSL el sıkışma gecikmesi hakkında harika bir makale (biraz eski, ama yine de harika). Uygulamamı yavaş Internet bağlantıları üzerinden kullanan müşteriler için yavaşlığın ana nedeni olarak SSL'yi tanımlamama yardımcı oldu:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Projem için aynı sorunu araştırdığım için bu slaytları buldum. Eski ama ilginç:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Burada kötü bir durum var gibi görünüyor: Sıkışık wifi üzerinden Ajax.

Ajax genellikle KeepAlive'in 20 saniye sonra zaman aşımına uğradığı anlamına gelir. Ancak, wifi (ideal olarak hızlı) ajax bağlantı birden fazla gidiş-dönüş yapmak zorunda olduğu anlamına gelir. Daha da kötüsü, wifi genellikle paketleri kaybeder ve TCP yeniden iletimleri vardır. Bu durumda, HTTPS gerçekten çok kötü bir performans sergiliyor!

TLS henüz hızlı mı? Evet.

• İzleyin: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Oku: https://istlsfastyet.com/

Orada çizgileri bulanıklaştırmayı ve HTTPS'yi hızlı hale getirmeyi amaçlayan birçok proje var. SPDY ve mod- spdy gibi .

HTTP VS HTTPS PERFORMANS KARŞILAŞTIRMASI

HTTPS'yi her zaman düz eski HTTP ile karşılaştırıldığında daha yavaş sayfa yükleme süreleriyle ilişkilendirdim. Bir web geliştiricisi olarak, web sayfası performansı benim için önemlidir ve web sayfalarımın performansını yavaşlatan herhangi bir şey hayır.

İlgili performans sonuçlarını anlamak için, aşağıdaki şema HTTPS kullanarak bir kaynak için istekte bulunduğunuzda kaputun altında neler olduğuna dair temel bir fikir vermektedir.

Yukarıdaki şemadan da görebileceğiniz gibi, HTTPS kullanılırken düz HTTP kullanmaya kıyasla yapılması gereken birkaç ek adım vardır. HTTPS kullanarak bir istekte bulunduğunuzda, isteğin gerçekliğini doğrulamak için bir el sıkışma olması gerekir. Bu el sıkışma, bir HTTP isteğine kıyasla ekstra bir adımdır ve maalesef biraz ek yüke neden olur.

Performans sonuçlarını anlamak ve performans etkisinin önemli olup olmadığını kendim görmek için bu siteyi bir test platformu olarak kullandım. Webpagetest.org'a gittim ve HTTPS vs HTTP kullanarak bu site yüklemesini karşılaştırmak için görsel karşılaştırma aracını kullandım.

Gördüğünüz gibi İşte test videosu HTTPS kullanarak sonuç sayfamın yüklenme süreleri üzerinde bir etkisi oldu, ancak fark göz ardı edilebilir ve sadece 300 milisaniyelik bir fark fark ettim. Bu sürelerin bilgisayar performansı, bağlantı hızı, sunucu yükü ve sunucudan uzaklığı gibi birçok faktöre bağlı olduğunu unutmamak önemlidir.

Siteniz farklı olabilir ve sitenizi ayrıntılı bir şekilde test etmek ve HTTPS'ye geçişle ilgili performans etkisini kontrol etmek önemlidir.

Bunu ölçmenin bir yolu var. Apache'den jmeter adlı araç, iş hacmini ölçer. Hizmetinizin büyük bir örneklemesini jmeter ile, kontrollü bir ortamda, SSL olmadan ve SSL olmadan ayarladıysanız, göreli maliyetin doğru bir karşılaştırmasını almanız gerekir. Sonuçlarınızla ilgilenirim.

HTTPS'nin şifreleme / şifre çözme yükü vardır, bu nedenle her zaman biraz daha yavaş olacaktır. SSL sonlandırma çok CPU yoğundur. SSL'yi yükleyecek cihazlarınız varsa, gecikme süreleri arasındaki fark, sunucularınızın altındaki yüke bağlı olarak zar zor fark edilebilir.

Daha önemli bir performans farkı, kullanıcı bağlıyken HTTPS oturumunun ketp açık olmasıdır. HTTP 'oturumu' yalnızca tek bir öğe isteği için sürer.

Çok sayıda eşzamanlı kullanıcısı olan bir site çalıştırıyorsunuz, çok fazla bellek almayı bekliyoruz.

SSL'nin SLL olmayan HTTP'nin gerektirmediği ekstra bir şifreleme adımı gerektirdiği göz önüne alındığında, bu neredeyse kesinlikle doğru olacaktır.

HTTPS gerçekten sayfa hızını etkiler ...

Yukarıdaki alıntılar birçok kişinin site güvenliği ve hızı konusundaki aptallığını ortaya koymaktadır. HTTPS / SSL sunucusu el sıkışma, İnternet bağlantıları kurulurken ilk durak oluşturur. Ziyaretçinizin tarayıcı ekranında herhangi bir şey görüntülenmeye başlamadan önce yavaş bir gecikme olur. Bu gecikme İlk Bayt Süresi bilgisinde ölçülür.

HTTPS el sıkışma yükü, İlk Bayt Süresi bilgisinde (TTFB) görünür. Ortak TTFB 100 milisaniyenin altında (en iyi durum) 1,5 saniyenin üzerinde (en kötü durum) değişir. Ancak, elbette, HTTPS ile 500 milisaniye daha kötü.

Gidiş-dönüş, kablosuz 3G bağlantıları 500 milisaniye veya daha fazla olabilir. Ekstra açma 1 saniye veya daha fazla gecikme. Bu, mobil performans üzerinde büyük ve olumsuz bir etkidir. Çok kötü bir haber.

Benim tavsiyem, hassas veri alışverişi yapmıyorsanız o zaman SSL'ye ihtiyacınız yoktur, ancak bir e-ticaret web sitesini seviyorsanız, HTTPS'yi yalnızca Giriş ve ödeme gibi hassas verilerin paylaşıldığı belirli sayfalarda etkinleştirebilirsiniz.

Kaynak: Pagepipe

Tarayıcılar HTTP veya HTTPS ile HTTP / 1.1 protokolünü kabul edebilir, ancak tarayıcılar yalnızca HTTPS ile HTTP / 2.0 protokolünü işleyebilir. HTTP / 1.1 ile HTTP / 2.0 arasındaki protokol farklılıkları HTTP / 2.0'ı HTTP / 1.1'den ortalama 4-5 kat daha hızlı yapar. Ayrıca, HTTPS uygulayan sitelerin çoğu bunu HTTP / 2.0 protokolü üzerinden yapar. Bu nedenle, HTTPS, genellikle kullandığı farklı protokol nedeniyle neredeyse her zaman HTTP'den daha hızlı olacaktır. Ancak, HTTP / 1.1 üzerinden HTTP, HTTP / 1.1 üzerinden HTTPS ile karşılaştırılırsa, HTTP, HTTPS'den ortalama olarak biraz daha hızlıdır.

Chrome (Ver. 64) kullanarak çalıştırdığım bazı karşılaştırmalar şunlardır:

HTTP / 1.1 üzerinden HTTPS:

• Ortalama sayfa yükleme süresi 0.47 saniye
• HTTP / 1.1 üzerinden HTTP'den 0.05 saniye daha yavaş
• HTTP / 2.0 üzerinden HTTPS'den 0,37 saniye daha yavaş

HTTP / 1.1 üzerinden HTTP

• Ortalama sayfa yükleme süresi 0.42 saniye
• HTTP / 1.1 üzerinden HTTPS'den 0,05 saniye daha hızlı
• HTTP / 2.0 üzerinden HTTPS'den 0,32 saniye daha yavaş

HTTP / 2.0 üzerinden HTTPS

• Ortalama yükleme süresi 0.10 saniye
• HTTP / 1.1 üzerinden HTTP'den 0,32 saniye daha hızlı
• HTTPS / 1.1 üzerinden HTTPS'den 0,37 saniye daha hızlı