Apache :: HTTPS erittäin hidas tai ei vastaa

Kirjoittaja QmpeltatyLiittynyt: 6. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: pe 17. tammikuuta 2014 15:38Viestin aihe: HTTPS erittäin hidas tai ei vastaa Minulla on ongelma hitaassa Apache 2.4.4:ssä. Se liittyy vain https:ään, joka on yleensä 5 kertaa hitaampi kuin sama sivusto http:n kautta. Näen tämän eron valvontaohjelmistossa, joka mittaa vasteaikaa http:lle ja https:lle 5 sekunnin välein. Joissain tapauksissa sain jopa aikakatkaisuja selaimessa https:ssä, kun samaan aikaan sivusto avautuu http:n yli - hitaasti mutta avautuu aina. Apache toimii Win2k8 Enterprisella, versiolla 2.4.4 x64 - VC10. Palvelin on yhdistetty melko huonolla Internet-yhteydellä, koska se sijaitsee Afrikassa. Yhteyden laadusta huolimatta http toimii kunnolla koko ajan.Takaisin alkuunjrauteLiittynyt: 13. syyskuuta 2013Viestit: 188Sijainti: Rheinland, Saksa Lähetetty: pe 17. tammikuuta 14 18:31Viestin aihe:Voitko kertoa meille jotain määrityksistäsi (httpd) ja ssl:stä toteutus?Esimerkiksi yli 2048-bittiset "dh-avaimet" sisältävät salauspaketit vievät jonkin aikaa. Ja Windows-järjestelmissä on joitain parametreja, jotka auttavat parantamaan suorituskykyä.TervehdysJRBalkuunQmpeltatyLiittynyt: 6. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: la 18. tammikuuta '14 17:31Viestin otsikko:ssl.conf : Koodi:Kuuntele 192.168.1.65:443 httpsAddType application/x-x509-ca-cert .crtAddType application/x-pkcs7-crl.crlSSLPassPhraseDialogshAbctin/ s/ ssl_scache(512000)"SSLSessionCacheTimeout300Mutex defaultDocumentRoot "C:/Apache24/htdocs"Palvelinnimi mydomain.comPalvelinAlias ​​www.omaverkkotunnus.comPalvelinAlias ​​other_mydomain.comServerAlias ​​other_mydomain.comServerAlias ​​other_mydomain.comServerAlias. .log"SSLengine onSSLProtocol -ALL +SSLv3 +TLSv1SSLCipherSuite ALL :!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUMSSLCertificateFile "conf/ssl/server.crt"SSLCertificateKeyFile "conf/ssl/server.key"SSLCertificateChainFile/conf/sl ca_bundle.crt"SSLOptions +StdEnvVarsSSLOptions +StdEnvVarsBrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0Takaisin alkuunjrauteLiittynyt:013Postlands,Rhe8Sijainti2:13Sijainp8:0 Lähetetty: la 18 tammikuu ' 14 21:10 Viestin otsikko:Ok. Miten mitasit eron? Onko se monimutkainen verkkosivusto? Millaista selainta käytät? (jos mahdollista pls testaa firefoxilla). Ssl.conf-tiedostosi näyttää hyvältä, vaikka vaihtaisin koodin Code:BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0Uudemmissa MSIE:ssä ei pitäisi olla mahdolliset ongelmat ssl-uudelleenneuvottelussa: Siksi kokeilisin: Code:BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0BrowserMatch "MSIE [16-9]" ssl-uncleanessshutdownB Kaiken tämän haluaisin kysyä, onko palvelimessa useampi kuin yksi nic asennettuna, ja jos on, kuinka sidonta on määritetty, koska käytät omistettua IP-osoitetta vhost-kokoonpanoon. joskus se on ongelma sidonnassa. Tarkista lopuksi palomuurisi, jos palvelin on sijoitettu dmz:hen. Viimeksi muokannut jraute ma 27. tammikuuta 14 17:36; muokattu yhteensä 1 kerranTakaisin alkuunQmpeltatyLiittynyt: 06. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: ma 20. tammikuuta '14 9:48Viestin aihe: jraute kirjoitti:Ok. Miten mittasit eron? Minulla on valvontajärjestelmä, joka tarkistaa jatkuvasti yhteyttä sekä http- että https-verkkoon. Saan varoitusilmoituksia vain https:stä. jraute kirjoitti:Onko se monimutkainen web-sivusto?Mitä tarkoitat monimutkaisella verkkosivustolla? jraute kirjoitti: Millaista selainta käytät? (jos mahdollista pls testaa firefoxilla). Tarkistettu myös FF - ei toimi myöskään. jraute kirjoitti:Ssl.conf-tiedostosi näyttää hyvältä, vaikka vaihtaisin BrowserMatchin ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0Uudemmilla MSIE:llä ei pitäisi olla ongelmia ssl-renegotiation kanssa :Siksi kokeilisin:BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown \downgrade-1.0 force-response-1.0BrowserMatch "MSIE [16-9]" ssl-unclean-shutdownKiitos, harkitsen tätä muutosta . jraute kirjoitti: Kaiken tämän lisäksi haluaisin kysyä, onko palvelimella useampi kuin yksi nic asennettuna ja jos on, kuinka sidonta on määritetty, koska käytät omistettua IP-osoitetta vhost-kokoonpanoon. Joskus se on ongelma sitomisessa. Tämä on virtuaalikone, jossa on yksi virtuaalinen nic. Minulla on useita yksityisten verkkojen IP-osoitteita määritettynä, Apache toimii tietyllä IP-osoitteella, ei jaettu muiden palvelujen kanssa.jraute kirjoitti: Tarkista vihdoin palomuurisi, jos palvelin on sijoitettu dmz:hen. Palomuuriasetuksia ei ole muutettu yli vuoteen. Mietin, onko https-yhteys paljon "resursseja vaativampi" kuin http, vaatiiko se vakaamman nettiyhteyden, enemmän palvelinresursseja jne. - palvelinpuolella? Kuten mainitsin, palvelin sijaitsee Afrikassa, melko huonolaatuisella yhteydellä - ihmettelen, voisiko sillä olla vaikutusta. Toisaalta http toimii koko ajan, ilman ongelmia.Takaisin alkuunSteffenModeraattoriLiittynyt: 15.10.2005Viestit: 2873Sijainti: Hilversum, NL,EULähetetty: Ma 20. tammikuuta '14 13:07Viestin aihe: Onko Apache error.logissa ja/tai Windowsin tapahtumien katseluohjelmassa merkkejä? Onko sinulla httpd.conf:AcceptFilter http none AcceptFilter https none EnableSendfile pois EnableMMAP offTakaisin alkuunQmp : 06. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: Ma 20. tammikuuta 2014 14:18Viestin aihe: Steffen kirjoitti: Onko Apache error.logissa ja/tai Windowsin tapahtumien katseluohjelmassa merkkejä? Virheloki on selkeä. Tapahtumien katseluohjelmassa olen löytänyt kaksi virhettä, molemmat näkyvät vain, kun Apache käynnistetään uudelleen: Koodi:"Viallisen sovelluksen nimi: httpd.exe, versio: 2.4.4.0, aikaleima: 0x5127dda0Viallisen moduulin nimi: SSLEAY32.dll, versio: 1.0.1.5, aikaleima: 0x5123e06cPoikkeuskoodi: 0xc0000005Vikapoikkeama: 0x000000000015e99Viallisen prosessin tunnus: 0x7360Viallisen sovelluksen aloitusaika: 0x01pache sovelluksen aloitusaika: 0x01 sovellus \bin\httpd.exeViallisen moduulin polku: C:\Apache24\bin\SSLEAY32.dllRaportin tunnus : b159de2a-8056-11e3-91ac-005056934851" Koodi:Viallisen sovelluksen nimi: httpd.exe, versio: 2.4.4.0, aikaleima: 0x5127dda0Viallisen moduulin nimi: ntdll.dll, versio: 4.1 2.1 sta 2.1 6.1 .8 f24Poikkeuskoodi: 0xc0000374Vikapoikkeama: 0x00000000000c4102Viallisen prosessin tunnus: 0x6bacViallisen sovelluksen aloitusaika: 0x01cf1462efff97ebViallisen sovelluksen polku: C:\Apache24\bin\Windows\Windows\DllPt3:PakuFadll:http://module.exe d: 7b2f4f2f-8056-11e3-91ac-005056934851 Steffen kirjoitti:Onko sinulla httpd.conf:AcceptFilterissäsi http none AcceptFilter https none EnableSendfile off EnableMMAP offKyllä.Uskon, että ensimmäinen asia, jonka tekisin, on päivittää versioon 2.4.7.Takaisin alkuunSteffenModeratorLiittynyt: 15. lokakuuta:88. , NL, EULähetetty: ma 20. tammikuuta '14 14:34Viestin aihe:Joo, päivitä ensin versioon 2.4.7, melko paljon korjauksia myös hitaan/huonon yhteyden alueella.Takaisin alkuunJrauteLiittynyt: 13.9.2013Viestit: 188Sijainti: Rheinland, Saksa Ma 20. tammikuuta '14 18:29Viestin aihe: Qmpeltaty kirjoitti: jraute kirjoitti:Onko se monimutkainen web-sivusto?Mitä tarkoitat monimutkaisilla verkkosivuilla?Ajattelin verkkosivuja, joissa on useita elementtejä, skriptejä ja dynaamista sisältöä. Se voi olla ongelmallista.Btw, otitko käyttöön mod_deflaten?Takaisin alkuunQmpeltatyLiittynyt: 06. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: tiistai 21. tammikuuta '14 12:11Viestin aihe: jraute kirjoitti: Qmpeltaty kirjoitti: jraute kirjoitti: Onko se monimutkainen web:-sivusto? Mitä tarkoitat monimutkaisilla web-sivustoilla? Ajattelin verkkosivuja, joissa on useita elementtejä, skriptejä ja dynaamista sisältöä. Se voi olla ongelmallista. Otitko käyttöön mod_deflaten? Tässä mielessä - Kyllä, sivustoni ovat monimutkaisia. Suurin osa sisällöstä palvelee JBoss-sovelluspalvelinta, jota edustaa tämä ilmentymä apache, jonka kanssa minulla on ongelma - mod_jk-moduulin kautta. Mitä tulee mod_deflate - se on toteutettu. Deflate.conf : Code:SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|rz| ) $ no-gzip dont-toary setenvifnocase request_uri \ .pdf $ no-gzip dont-tomy #addoutputfilterbytype deflate text/css-sovellus/javaScriptAdDoutputFilterByType Deflate Text/HTML-teksti/Plain Text/XML-teksti/CSS-teksti /4 GZIP-vain-teksti/htmlbrowerMatch ^mozilla/4 \ .0 [678] no-gzipbrowermatch \ bmsi [e]! No-gzip! topjrauteLiittynyt: 13. syyskuuta 2013Viestit: 188Sijainti: Rheinland, Saksa Lähetetty: ti 21. tammikuuta 14 15:35Viestin aihe:Päivitys on varmasti hyvä asia.Viimeinen idea: Oletko mitannut suorituskyvyn https:n kautta palvelimesi yksinkertaiselle html-sivulle?Jos että nopeus on lähes sama kuin http:llä, niin sivusi asettelu/-kokoonpano on ongelma. (Muistan kaverin, joka analysoi sivun nopeuden ja aloitti sivustolla, jonka latausaika oli 12 sekuntia. useiden parannusten jälkeen, lähinnä sivun suunnittelussa, sama sisältö latautuu 1,3 sekunnissa.)Jos yksinkertaisella html-sivulla on sama ongelma, kannattaa yrittää analysoida verkkoliikennettä ja mitä tcp-paketit tekevät.[vitsitila päällä ] nsa tarvitsee jonkin aikaa ssl-istunnon salauksen purkamiseen[vitsitila pois päältä]Takaisin alkuunQmpeltatyLiittynyt: 06. helmikuuta 2008Viestit: 182Sijainti: Puola Lähetetty: ke 22. tammikuuta 14 15:15Viestin aihe: jraute kirjoitti:Päivitys on varmasti hyvä asia. idea: Oletko mitannut suorituskyvyn https:n kautta palvelimesi yksinkertaiselle html-sivulle?Valvontajärjestelmäni tarkistaa yhteysaikaa yksinkertaiseen html-sivuun - kun https toimii hitaasti, http toimii hyvin.Takaisin alkuunjrauteLiittynyt: 13. syyskuuta 2013Viestit: 188Sijainti : Rheinland, Saksa Lähetetty: ke 22. tammikuuta '14 22:13Viestin aihe:Ok, siellä on verkkosivutestisivusto, joka analysoi, mitä sivua ladattaessa tapahtuu. http://www.webpagetest.orgEhkä se auttaa sinua tunnistamaan sivun osan. latausprosessi, joka maksaa suurimman osan ajasta.(Klikkaa vain vesiputousnäkymää) Sen jälkeen ratkaisun löytäminen on hieman helpompaa, vaikka en ole varma, löytyykö ratkaisua. Viimeksi muokannut jraute pe 24. tammikuuta 14 10:54; Muokattu 1 -kertaisesti TopJames BlondModerator -sovellukseen: 19. tammikuuta 2006Postit: 6998Location: Saksa, Hampurin vieressä topqmpeTatyJoined: 06. helmikuuta 2008PostS: 182Location: PolandPosted: pe 24. tammikuuta '14 14: 33post: Arviointi epäonnistui topjrauteLiittynyt: 13. syyskuuta 2013Viestit: 188Paikka: Rheinland, Saksa Lähetetty: pe 24. tammikuuta 14 15:11Viestin aihe:Ok, kiitos palaamisesta ja jakamisesta. Jos arviointi epäonnistuu, kädenpuristus ei toiminut. Tälle käytökselle voi olla useita syitä: Aikakatkaisu, skriptien estäminen, palomuuri, tuntemattomat laajennukset, väärä salausjärjestys. pls tarkista tämä: http://sourceforge.net/mailarchive/message.php?msg_id=31805015Ja ehkä ongelma voidaan helposti ratkaista määrittämällä toimiva ssl-salauspakettiyhdistelmä.TervehdysJRBakaisin alkuunQmpeltatyLiittynyt: 06 helmikuu 2008Viestit: 182Sijainti: Puola Lähetetty: pe 24 tammikuu '14 15:27Viestin aihe:Kuten sanoin, tämä yhteys on melko laadukas Afrikassa. huono, mutta http toimii koko ajan. Apache on juuri päivitetty versioon 2.4.7, eikä se auttanut.Takaisin alkuunJrauteLiittynyt: 13. syyskuuta 2013Viestit: 188Sijainti: Rheinland, Saksa Lähetetty: la 25. tammikuuta 2014 1:21Viestin aihe:Muut ideat:1. onko sinulla rdp-yhteys palvelimeesi? Sitten voit testata https://127.0.0.1/... ja katsoa toimiiko se.2. jos mahdollista, yritä testata "keskitason" luokan salaussarjoilla.3. tarkista, toimivatko avaimet ja ca-tiedosto.Takaisin alkuunQmpeltatyLiittynyt: 06.2.2008Viestit: 182Sijainti: PuolaLähetetty: Ma 27.1.2014 18:04Viestin aihe: jraute kirjoitti:Muita ideoita:1. onko sinulla rdp-yhteys palvelimeesi? Sitten voisi testata https://127.0.0.1/... ja katsoa toimiiko se. Tein, ei toimi myöskään paikallisesti.jraute kirjoitti:2. jos mahdollista, yritä testata "keskikokoisen" luokan salaussarjoilla.Kuinka minun pitäisi tehdä tämä? Pitäisikö minun poistaa HIGH-salaukset tiedostosta ssl.conf? jraute kirjoitti: 3. tarkista, toimivatko avaimet ja ca-tiedosto.Kuinka tarkistaa se päivitys versioon 2.4.7 voi olla hyödyllistä tarkastella lokitiedostoasi, kun apache käynnistyy. Onko ssleay-virhe edelleen olemassa? Ehkä meidän pitäisi myös tarkastella sitä. Testiä varten voit yrittää poistaa "korkean" määritelmän SSLCipherSuitesta ja kommentoida SSLCertificateChainFile. Sitten saat varmenneavain-tiedosto-yhdistelmän, jota ei voida varmentaa ca-ketjua vastaan. mutta testaamaan ketä kiinnostaa - joskus on hyvä aloittaa mahdollisimman yksinkertaisella.(tässä tapauksessa selaimessa pitäisi hyväksyä, että avainta ei ole allekirjoittanut luotettava CA ja jatka ...)Jos et ole varma jos varmenne toimii, voit rakentaa sellaisen itse openssl:llä. (kysy tarvittaessa ohje) yritä aloittaa testi pienemmillä näppäimillä, koska yli 1024 bitin avaimet yhdessä joidenkin salauspakettien kanssa voivat aiheuttaa viiveitä.TervehditJRLmuokannut jraute ma 27. tammikuuta '14 19:08 ;