A "jobban" szót nem használnám, inkább "másképp". Az nginx "állapotmentes", akkor izgul rá egy kérésre amikor az már az utolsó bit-ig bejött, és tolja is ki a választ ahogy a csövön kifér kvázi fire and forget alapon. Emiatt a lassú kérések nem/nehezen tudják betelíteni, cserében a mögöttes infra terhelés elleni védelmére sem jó (illetve lehet az, de másképp).
A TCP is csak a pufferek és a státusztáblák méretéig állapottartó, ami oda nem fér be azt elhajtja, és egyben a protokoll sajátosságai miatt a fogadó le tudja szabályozni a küldőt hogy "hé, lassítsál már". Ha az leszarja, akkor meg el lesznek dobálva a csomagjai. A webszerverek és a webes kliensek közt nincs ilyen szabványos szabályzó protokoll (ha lenne, a támadók úgyis letojnák), így L7-be az L3 réteg sebességével megérkeznek a kérések.
A hívó böngészők és a kiszolgáló webszerver közt általában csak hálózati eszközök vannak, azok pedig csak addig pufferelnek, amíg a csomag darabkái megérkeznek, azaz L7 szempontjából kvázi sehogy. Amikor sok hívó van, ezek sebessége különbözik, vagy a hívások alkalmazásszerverben végződnek, ahol vannak lassabb válaszidők is, és mondjuk peak-ben több kérés jön be mint amennyit egyszerre kezelni tudsz, valakinek a kéréseket késleltetnie kell hogy ne dögöljön bele a backend infra. Ha nincs ilyen a láncban, akkor ha nem korlátoztál hálózati eszközön, megdöglik a backend és annak a helyreállása hosszú idő (mire kipörögnek a kérések), ennél jobb, ha a hálózati eszközökön forgalmi korlát van a backend kiszolgálási képesség alá kicsivel belőve. Viszont mindkét esetben a felhasználók oldalán mindenképpen megjelenik a hiba (connection reset, timeout, még a http error code sem tud visszamenni). Ami nem szép, mert ugye kultúráltabb, ha vissza tudsz adni legalább egy hibaoldalt hogy "bocs, túlterhelés van, próbáld meg később". Persze mint mindent ezt is meg lehet oldani sokféleképpen, pl ha SPA-t tolsz ki kliens oldalra hosszú local cache idővel és az maga inti türelemre a felhasználót.