🌐 BI-AWD – Administrace webového serveru

📌 Co je databázová administrace a kdo je DBA?

DBA (Database Administrator) musí zvládat všechny výše uvedené oblasti, mít solidní znalost hostitelského operačního systému a jeho konfigurace, a být komunikativní – spolupracuje s vývojáři, manažery i provozním týmem.

• Standardní správa: vytváření/rušení databází, schémat, uživatelů, rolí, tablespaces
• Backup & Recovery: logické i fyzické zálohy, PITR (Point-in-Time Recovery)
• Monitoring: sledování výkonu, zatížení, chybových stavů
• Bezpečnost: autentizace, autorizace, šifrování spojení
• Ladění výkonu (Tuning): optimalizace SQL, indexy, statistiky, execution plány
• Replikace: nastavení a správa logické/fyzické replikace
• Troubleshooting: diagnostika a oprava chyb, konfliktů, blokací

🐘 PostgreSQL – přehled a historický kontext

• Kód PostgreSQL sloužil jako základ pro jiné databázové enginy (Ingres, Sybase, …)
• Aktuální verze: PostgreSQL 17 (+ 18 v přípravě, září 2025)
• ORDBMS = podporuje objektové rozšíření (dědičnost, vlastní datové typy, funkce)
• Open-source od začátku – BSD licence, silná komunita
• Enterprise funkce: replikace, full-text search, JSON/JSONB, PostGIS, …

🏗️ Architektura PostgreSQL – klíčové pojmy: Cluster, Instance, Databáze

Na jednom fyzickém serveru (OS nodu) může běžet více clusterů (různé verze PostgreSQL, různé porty). Každý cluster je spravován samostatně.

Logická hierarchie objektů

Fyzická struktura – $PGDATA adresář

• base/ – datové soubory jednotlivých databází (každá databáze = podadresář pojmenovaný OID)
• global/ – globální systémové katalogy (role, tablespaces, …) sdílené celým clusterem
• pg_wal/ – WAL (Write-Ahead Log) soubory – klíčové pro obnovu a replikaci
• pg_tblspc/ – symlinky na tablespace adresáře mimo $PGDATA
• postgresql.conf – hlavní konfigurační soubor instance
• pg_hba.conf – konfigurace autentizace (host-based authentication)
• pg_ident.conf – mapování OS uživatelů na DB uživatele
• PG_VERSION – verze PostgreSQL pro daný cluster
• postmaster.pid – PID hlavního procesu (přítomen jen při běhu)

⚙️ Systémové procesy PostgreSQL (Background Processes)

PostgreSQL používá multi-process model (ne multi-thread). Každé připojení klienta = nový OS proces.

Klíčové procesy a jejich úloha

🧠 Paměťové komponenty – Shared Buffers, WAL, Cache

• Shared Buffers: Stránky (datové bloky, velikost 8 KB) jsou do shared buffers načítány z disku při čtení a modifikovány při zápisu. "Dirty" = modifikovaná, ale ještě nezapsaná na disk.
• WAL Buffers: Paměťová oblast pro WAL záznamy (před jejich zápisem na disk do pg_wal/).
• Work_mem: Paměť pro řazení a hašovací operace per dotaz (resp. per uzel v execution plánu). Nastavení příliš nízké → spill to disk; příliš vysoké → OOM riziko při mnoha souběžných dotazech.
• Maintenance Work_mem: Paměť pro maintenance operace (VACUUM, CREATE INDEX, …).
• Effective Cache Size: Odhad (hint pro optimalizátor), jak velká část FS cache OS je k dispozici. Ovlivňuje volbu execution plánu, reálně nic nealokuje.

WAL – Write-Ahead Log

• Klíčový pro implementaci ACID – garantuje Durability (trvanlivost): i po pádu serveru lze z WAL obnovit stav databáze
• Klíčový pro PITR (Point-In-Time Recovery)
• Klíčový pro replikaci (logická i fyzická)
• LSN (Log Sequence Number) = ukazatel do WAL (pozice záznamu); používá se pro správu konzistence replikace
• WAL soubory jsou recyklovány (přepisovány) – nerostou do nekonečna
• wal_level – parametr určující množství informací v WAL: minimal | replica | logical

Checkpoint

• Řídí ho proces checkpointer
• Po checkpointu lze WAL záznamy před ním (v případě zotavení) přeskočit
• Vytváří se periodicky (checkpoint_timeout) nebo při naplnění WAL (max_wal_size)
• DBA může vynutit manuálně: CHECKPOINT;

📋 Konfigurační soubory – postgresql.conf, pg_hba.conf, pg_ident.conf

postgresql.conf – konfigurace instance

Hlavní konfigurační soubor celé instance (clusteru). Změny typicky vyžadují reload (pg_ctlcluster reload nebo SELECT pg_reload_conf();), některé vyžadují restart.

• listen_addresses = '*' – na jakých IP adresách naslouchat (výchozí: localhost)
• port = 5432 – port serveru
• max_connections – maximální počet současných klientských připojení
• shared_buffers – velikost sdílené cache
• work_mem – paměť pro sort/hash per operaci
• wal_level = logical – nutné pro logickou replikaci
• log_* – parametry logování (log_min_duration_statement, log_connections, …)
• shared_preload_libraries – rozšíření načtená při startu (např. pg_stat_statements)
• track_activities, track_counts, track_functions – nastavení statistik
• Zobrazení aktuálního nastavení: SELECT * FROM pg_settings; nebo SHOW ALL;
• Změna za běhu: ALTER SYSTEM SET parametr = hodnota; (zapíše do postgresql.auto.conf)

pg_hba.conf – Host-Based Authentication

Formát záznamu:

# type   database  user   address         method
local    all       all                    peer
host     all       all    127.0.0.1/32    scram-sha-256
host     all       all    0.0.0.0/0       scram-sha-256

• Záznamy se procházejí shora dolů, první shoda platí
• Po výchozí instalaci: nikdo z venku se nemůže připojit (bezpečnostní výchozí stav)
• Otevření pro vzdálená připojení: změnit pg_hba.conf + nastavit listen_addresses = '*' + restart/reload

pg_ident.conf

Mapuje OS uživatelská jména na databázové uživatele (použitelné pro metody ident a peer). Např. OS uživatel jan → DB uživatel app_user.

.pgpass soubor

Umožňuje automatické přihlašování bez zadávání hesla (uložení hesla v ~/.pgpass). Formát: hostname:port:database:username:password. Soubor musí mít práva 400 (jinak ho PostgreSQL ignoruje). Vhodné pro adminy a scripty, ale hesla jsou v plaintextu!

👤 Role, uživatelé a správa přístupu

Klíčové atributy role

• CREATE USER jmeno WITH PASSWORD 'heslo'; – vytvoří roli s LOGIN atributem
• CREATE ROLE skupinova_role; – skupinová role bez LOGIN
• GRANT skupinova_role TO uzivatel; – přidání uživatele do skupiny
• REVOKE skupinova_role FROM uzivatel; – odebrání
• \du – zobrazí role s atributy v psql
• SELECT SESSION_USER, CURRENT_USER; – aktuální uživatel
• SET ROLE jmeno; – přepnutí role v rámci session

📦 Databáze, Schémata a Tablespaces

Vytváření databáze

• template0 = "čistá" kopie template1 z doby inicializace clusteru (bez žádných rozšíření). Vhodná pro obnovu ze zálohy s jiným locale.
• CREATE DATABASE db_name TEMPLATE template1; – vytvoření databáze
• CREATE DATABASE db_name TEMPLATE template0 LOCALE 'cs_CZ.utf8'; – s jiným locale
• Databáze fyzicky odpovídá adresáři v $PGDATA/base/<OID>/

Schémata (Schemas)

• Výchozí schema: public
• search_path = seznam schémat, ve kterých se hledají objekty bez explicitního prefixu
• SET search_path = my_schema; – nastavení v psql
• SHOW search_path; – zobrazení aktuálního search_path
• Různé aplikace mohou sdílet jednu databázi přes různá schémata (multi-tenant)

Tablespaces

• Praktické použití: kriticky zatížené tabulky/indexy na SSD, archivní data na HDD
• CREATE TABLESPACE fastspace LOCATION '/ssd1/postgresql/data';
• CREATE TABLE velka_tabulka (...) TABLESPACE fastspace;
• ALTER TABLE tabulka SET TABLESPACE jiny_tablespace; – přesun objektu
• \db+ – zobrazení tablespaces v psql; nebo SELECT * FROM pg_tablespace;

💾 Zálohování a obnova (Backup & Recovery)

Typy záloh

pg_dump / pg_restore – logická záloha (preferovaná pro vývojáře/adminy)

• pg_dump -Fc dbname > backup.dump – záloha ve vlastním formátu (custom, doporučeno)
• pg_dump -Fp dbname > backup.sql – plain SQL formát
• pg_dumpall > all_databases.sql – záloha celého clusteru včetně rolí
• pg_restore -d newdb backup.dump – obnova ze zálohy
• Přepínače: --schema-only, --data-only, --table=jmeno, --no-owner, …

Online (hot) fyzická záloha + PITR

• Fyzická kopie běžící databáze není sama o sobě konzistentní (partial writes)
• WAL záznamy popisují všechny změny od posledního checkpointu – přehráním WAL lze přivést base backup do konzistentního stavu
• Archivace WAL: archive_mode = on, archive_command v postgresql.conf
• Obnova: rozbalení base backupu + konfigurace recovery.conf (PostgreSQL 12+: recovery_target_time v postgresql.conf)
• Logická replikace je postavena na stejném principu jako PITR (WAL dekódování)

🔄 Přesun dat – COPY a \copy

• \copy tabulka FROM 'soubor.csv' WITH CSV HEADER;
• \copy (SELECT ...) TO 'export.csv' WITH CSV HEADER;
• CSV formát je velmi praktický a rychlý pro přenos dat mezi databázemi
• Výrazně rychlejší než INSERT INTO ... VALUES(...); (generovaný pg_dumpem)
• Excel umí číst CSV – snadné reportování uživatelům

📊 Monitoring, ladění výkonu a optimalizace SQL

Cumulative Statistics System

PostgreSQL automaticky sbírá statistiky o aktivitě serveru. Parametry: track_activities, track_counts, track_functions, track_io_timing, track_wal_io_timing.

• Dynamické statistické pohledy – aktuální stav systému (např. pg_stat_activity – aktivní dotazy)
• Kumulované statistické pohledy – nashromážděné statistiky od startu/resetu
• pg_stat_all_tables – statistiky per tabulka (seq scany, index scany, mrtvé řádky, …)
• pg_stat_all_indexes – využití indexů (klíčové pro nalezení nepoužívaných indexů)
• pg_stat_bgwriter – statistiky bgwriteru a checkpointů
• pg_stat_replication – stav replikačních připojení

Logování – nastavení v postgresql.conf

log_line_prefix = '%t [%p]: [%l-1] '
log_min_duration_statement = 0    -- logovat všechny dotazy (0 = všechny)
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0
log_destination = 'csvlog'
log_directory = '/work/pglogs'
log_statement = 'all'
logging_collector = on
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'

Nástroje pro monitoring a analýzu

• pgbadger – analýza PostgreSQL logů, generuje HTML report se statistikami pomalých dotazů
• pg_bench – generátor zátěže (implementace TPC-B benchmarku); simuluje bankovní transakce
• pgAdmin – grafická administrační aplikace (doporučen přes Docker)
• DataGrip – spíše pro vývojáře
• OS nástroje: top, htop, iostat, vmstat

pg_bench – generování zátěže

createdb example
pgbench -i -s 5 example           # inicializace testovací DB (scale factor 5)
pgbench -c 10 -j 2 -t 10000 example  # 10 klientů, 2 thready, 10000 transakcí

TPC-B simuluje banku s pobočkami a klienty manipulujícími s účty. TPC-C a TPC-E jsou modernější benchmarky používané v praxi.

Oracle AWR (pro srovnání)

Oracle má automatizovanou infrastrukturu pro monitoring: AWR (Automatic Workload Repository) ukládá snapshoty zatížení, na jejichž základě fungují automatičtí "advisors" (Index Advisor, Memory Advisor, …). PostgreSQL tento mechanismus nativně nemá, ale pg_stat_statements a pgBadger pokrývají podobné potřeby.

🔍 SQL Optimalizace – EXPLAIN, indexy, statistiky, materializované pohledy

Princip cost-based optimalizace

• Cost = odhadovaná cena v abstraktních jednotkách (page reads, CPU operations)
• Plán = strom operací; listy jsou zdroje dat (Seq Scan, Index Scan), uzly jsou operace (Join, Sort, Hash, …)

EXPLAIN a EXPLAIN ANALYZE

• EXPLAIN dotaz; – zobrazí odhadovaný execution plán (cost, rows, width)
• EXPLAIN ANALYZE dotaz; – skutečně provede dotaz + zobrazí skutečné časy a počty řádků vs. odhadované
• EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) dotaz; – detailní výstup s buffer statistikami

Příklad výstupu EXPLAIN:

HashSetOp Except  (cost=0.00..33.14 rows=70 width=1056)
  ->  Append  (cost=0.00..31.90 rows=71 width=1056)
        ->  Subquery Scan on "*SELECT* 1"  (cost=0.00..11.40 rows=70 width=1056)
              ->  Seq Scan on animal  (cost=0.00..10.70 rows=70 width=1052)
        ->  Subquery Scan on "*SELECT* 2"  (cost=0.14..20.15 rows=1 width=1056)
              ->  Nested Loop  (cost=0.14..20.14 rows=1 width=1052)
                    ->  Seq Scan on examination  (cost=0.00..11.75 rows=1 width=4)
                          Filter: ((purpose)::text = 'nausea'::text)
                    ->  Index Scan using pk_animal on animal  (cost=0.14..8.16 rows=1)

Postup SQL optimalizace

1. Nalézt problematické (pomalé a/nebo časté) SQL dotazy → pg_stat_statements, pgbadger, logy
2. Zkoumat jejich execution plán (EXPLAIN ANALYZE)
3. Pochopit plán a rozhodnout, jak ho zlepšit
4. Aplikovat změnu (index, rewrite dotazu, VACUUM, ANALYZE, …)
5. Ověřit, že se situace zlepšila
6. Typicky nutno řešit dotaz po dotazu

Indexy

• PRIMARY KEY a UNIQUE constraint automaticky vytvoří index
• CREATE INDEX emp_name_idx ON employee(surname, firstname); – composites index
• CREATE INDEX CONCURRENTLY idx ON velka_tab(col); – bez blokování DML
• Index zrychluje čtení, ale zpomaluje DML (insert/update/delete musí udržovat index)
• Typy indexů: B-tree (výchozí), Hash, GiST, SP-GiST, GIN (pro pole, JSONB), BRIN (pro velké tabulky s korekcí dle pozice)
• Nalezení chybějících indexů přes pg_stat_all_tables: tabulky s mnoha seq scany a málo index scany
• Nalezení nepoužívaných indexů přes pg_stat_all_indexes

Statistiky (ANALYZE)

• Autovacuum daemon automaticky spouští ANALYZE (parametr autovacuum_analyze_threshold)
• Manuálně: ANALYZE; (celý cluster) nebo ANALYZE schema.tabulka;
• Statistiky lze spustit i na individuální sloupce: ANALYZE tabulka (sloupec);
• Správné statistiky = správné execution plány = dobrý výkon

Materializované pohledy (Materialized Views)

• Běžný VIEW = pouze uložený SELECT, při každém dotazu se provede znovu
• Materialized VIEW = výsledek uložen fyzicky, může mít indexy
• CREATE MATERIALIZED VIEW nazev AS SELECT ...;
• REFRESH MATERIALIZED VIEW nazev; – aktualizace dat (lze naplánovat cronjem)
• REFRESH MATERIALIZED VIEW CONCURRENTLY nazev; – bez zamknutí čtení (vyžaduje unique index)
• Vhodné pro: složité agregace, reporty, data, která se mění méně častem než jsou dotazována

🔧 Rozšíření PostgreSQL (Extensions)

• Dostupná rozšíření: SELECT * FROM pg_available_extensions;
• Nainstalovaná rozšíření: SELECT * FROM pg_extension;
• Instalace: CREATE EXTENSION jmeno_rozsireni; (per databáze!)
• Fyzické umístění: /usr/share/postgresql/<verze>/extension/ (Debian/Ubuntu)
• Shipped extensions v balíčku postgresql-contrib
• Existuje 1000+ extensions (na webu PostgreSQL)

Klíčová rozšíření

• PostGIS – prostorové (geografické) datové typy a funkce
• pg_trgm – trigram podobnostní vyhledávání (fuzzy matching)
• uuid-ossp – generování UUID
• hstore – key-value store uvnitř PostgreSQL sloupce
• db-links – vzdálené databázové spojení
• Různé typy indexů – bloom, rum, …

🔁 Logická replikace (Logical Replication)

Předpoklady

• wal_level = logical v postgresql.conf producenta (výchozí je replica)
• Funkční síťové spojení z consumera na producenta (subscription objekt obsahuje connection string)
• Dostatečná oprávnění role použité pro replikaci (atribut REPLICATION)
• Tabulky musí existovat na obou stranách (DDL se nereplikuje!)
• Pouze DML operace jsou replikovány (INSERT, UPDATE, DELETE) – ne DDL, sekvence, …

Klíčové koncepty

Procesy logické replikace

• Replication Launcher – periodicky kontroluje pg_subscription, spouští apply workery
• Apply Worker – zpracovává replikační stream per subscription, spouští tablesync workery per tabulku
• WAL Sender – na straně producenta; dekóduje WAL a posílá změny consumerovi; závisí na replication slotu

Rozšířené možnosti

• Row Filters – replikace pouze podmnožiny řádků (WHERE klauzule v CREATE PUBLICATION)
• Column Lists – replikace pouze podmnožiny sloupců (specifikace sloupců v CREATE PUBLICATION)
• Synchronous Commit – producent počká na potvrzení od consumera před potvrzením transakce (silnější garance konzistence, větší latence)

Monitorování

• Strana producenta: pg_publication, pg_publication_rel, pg_replication_slots
• Strana consumera: pg_subscription, pg_subscription_rel, pg_stat_subscription

Troubleshooting

• Pokud apply worker selže, replication launcher ho restartuje a požádá o replay od posledního potvrzeného LSN
• Přeskočení problematické transakce: ALTER SUBSCRIPTION sub SKIP (lsn = '0/1562C10');
• Alternativně: drop a recreate subscription (včetně initial data load)
• Pozor: lokální DML změny na consumerovi nejsou propagovány zpět na producenta, ale mohou být přepsány replikačními změnami z producenta!

🛠️ Nástroje DBA a psql

psql – terminálový klient

Doporučené prostředí pro psql

PSQL_EDITOR=vim          # editor pro úpravu bufferu uvnitř psql
PAGER=pspg -F --style=19 # pager pro zobrazení výsledků dotazů

Správa clusteru – základní příkazy (Debian/Ubuntu)

• pg_ctlcluster 17 main start|stop|restart|reload|status
• pg_lsclusters – seznam všech clusterů na serveru
• pg_createcluster 17 newcluster – vytvoření nového clusteru
• pg_dropcluster 17 oldcluster --stop – smazání clusteru

Připojení k databázi

• psql -h localhost -U uzivatel -d databaze – TCP/IP spojení (použije scram-sha-256 z pg_hba.conf)
• psql -U uzivatel -d databaze – socket spojení (použije peer auth)
• Connection string: psql "host=localhost dbname=mydb user=myuser password=mypass"

🕸️ Grafové databáze – Neo4j a NoSQL přehled

Motivace pro NoSQL

• RDBMS: rigidní schéma, chybí komplexní datové typy, aggregate-ignorant přístup
• NoSQL vznik po CAP teorému (2003, D. Brewer) a BigData requirements (3–5V)
• CAP teorém: Consistency, Availability, Partition tolerance – lze garantovat pouze 2 ze 3

NoSQL datové modely

ACID vs BASE

Neo4j – datový model

• Vertex (uzel) – může mít více labelů (např. :Person:Employee)
• Edge (hrana) – orientovaná, může mít právě jeden label; lze dotazovat i v opačném směru
• Property – key-value pár, přiřazený uzlu nebo hraně
• Schema-free databáze (flexibilní struktura)
• Cypher query language – deklarativní, inspirovaný SQL, intuitivní ASCII-art syntaxe

Cypher – základy dotazovacího jazyka

• Základní dotaz: MATCH ... RETURN ...
• Uzel: (a:AIRPORT) – proměnná a, label AIRPORT
• Vztah: (a:AIRPORT)-[:DIRECT]->(b:AIRPORT) – orientovaná hrana s labelem DIRECT
• Délka cesty: -[:DIRECT*1..5]-> – cesta délky 1 až 5 hran
• JSON vlastnosti: MATCH (s{code:'sf'})-[:DIRECT]->(d) RETURN s,d;
• Smazání všeho: MATCH(n) DETACH DELETE (n);
• Schéma: CALL db.schema.visualization();

Neo4j architektura a instalace

• Vyžaduje JRE 17+ (Neo4j 5)
• Verze: Community / Enterprise; Cloud / Standalone / Embedded; Desktop aplikace
• Spuštění: ./neo4j start, web klient na http://localhost:7474
• Výchozí přihlašovací údaje: neo4j/neo4j
• Lokální instalace: konfigurace adresářů pro data/logy/config – extrémně jednoduché

📝 Shrnutí okruhu a kontrolní otázky ke státnicím

Stručné shrnutí (5 klíčových bodů)

• Architektura PostgreSQL: Cluster = instance se svým $PGDATA; obsahuje více databází; databáze obsahuje schémata; multi-process model (postmaster + backend per spojení + background procesy)
• Konfigurace: Tři klíčové konfigurační soubory – postgresql.conf (instance), pg_hba.conf (autentizace), pg_ident.conf (mapování uživatelů)
• WAL je fundamentální: Write-Ahead Log je základem pro ACID (durability), PITR, replikaci; checkpoint zajišťuje, že dirty buffery jsou flushovány na disk
• Zálohování: Tři přístupy – logická záloha (pg_dump), fyzická studená záloha (cp/tar se zastavenou DB), fyzická online záloha (pg_basebackup + archivace WAL pro PITR)
• Logická replikace: Publication (producent) + Subscription (consumer); pouze DML (ne DDL); replication slot zajišťuje, že WAL není smazán před doručením; možné row filters a column lists

Kontrolní otázky (co bych měl umět říct u státnic)

📡 Základní vlastnosti protokolu HTTP

Klíčové vlastnosti:

• Textový protokol – zprávy jsou čitelné jako text (na rozdíl od binárních protokolů).
• Bezestavový – každý požadavek je nezávislý; server si nepamatuje předchozí interakce. (Stav se musí řešit cookies, sessions apod.)
• Aplikační vrstva ISO OSI – běží nad TCP/IP.
• Požadavek–odpověď – klient vždy iniciuje, server odpovídá.

Rozšíření HTTP/1.1 oproti HTTP/1.0

• Hlavička Host: – povinná; umožňuje name-based virtual hosting na jedné IP.
• Persistent (keep-alive) spojení – jedno TCP spojení pro více požadavků (Connection: close pro ukončení).
• Chunked encoding – odpověď rozdělena do bloků (Transfer-Encoding: chunked); vhodné když není předem známa velikost.
• Expect: 100-continue – klient se ptá, zda server přijme data před jejich odesláním.
• Vylepšená Cache-Control.

📨 Struktura HTTP zpráv

Požadavek (Request)

Method Request-URI HTTP-Version CRLF
[Header-Name: Header-Value CRLF]*
CRLF
[body]

Příklad:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

Odpověď (Response)

HTTP-Version Status-Code Reason-Phrase CRLF
[Header-Name: Header-Value CRLF]*
CRLF
[body]

Příklad:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234

<!DOCTYPE html>...

🔢 Stavové kódy HTTP

Číslice na začátku kódu určuje třídu. Pokud klient nerozumí konkrétnímu kódu, považuje ho za kód x00 (např. 499 → 400).

🛠️ HTTP metody

Server musí podporovat GET a HEAD. Ostatní metody jsou volitelné. REST API typicky používá GET, POST, PUT, DELETE.

🔗 URL, URI, IRI – identifikace zdrojů

Struktura URL

http://user:password@host:port/cesta?param1=val1&param2=val2#fragment

Znaky v URL

• Bezpečné (bez kódování): alfanumerické + $-_.+!*'()
• Nebezpečné (unsafe) – musí být kódovány: <>"#%{}[]|\^~`
• Vyhrazené (reserved) – speciální význam v URL: ;/?:@=& – pro jiné použití musí být kódovány
• Kódování: %XX kde XX je hexadecimální kód podle ISO 8859-1
• #fragment není součástí URL podle RFC – server ho nevidí, zpracovává ho klient

🔒 Bezpečnost přenosu dat – SSL/TLS a HTTPS

Verze protokolu

• SSLv2 (1995–2011) – dnes zakázán
• SSLv3 (1996–2015) – dnes zakázán (útok POODLE)
• TLSv1.0 (1999–2020) – deprecated
• TLSv1.1 (2006–2020) – deprecated
• TLSv1.2 (2008–) – aktuálně bezpečný
• TLSv1.3 (2018–) – nejmodernější, nejbezpečnější

TLS Handshake – jak probíhá

1. Klient pošle ClientHello (podporované šifry, verze TLS, náhodné číslo).
2. Server odešle ServerHello + certifikát + výběr šifry.
3. Klient ověří certifikát serveru (podpis CA, platnost, jméno).
4. Výměna klíčů (RSA nebo Diffie-Hellman/ECDH).
5. Obě strany odvodí session klíče.
6. Datový přenos je šifrovaný symetrickými klíči.

Bezpečnostní opatření TLS

• Klient ověřuje serverový certifikát vůči seznamu důvěryhodných CA.
• Porovnává DNS jméno serveru s CN/SAN v certifikátu (ochrana před MitM).
• Pořadová čísla zpráv v MAC (Message Authentication Code) – ochrana proti replay útokům.
• HMAC – ověřovací kód rozšířený o klíč; jen vlastník klíče dokáže ověřit.
• TLS Finished zpráva obsahuje hash všech handshake zpráv – detekce manipulace.

📜 PKI, certifikáty a CA

Struktura certifikátu X.509

• Subjekt (Subject) – komu byl vydán (DN: CN, O, OU, L, ST, C)
• Vydavatel (Issuer) – certifikační autorita
• Veřejný klíč subjektu
• Platnost – Not Before / Not After
• Digitální podpis CA – ověřitelný veřejným klíčem CA

Distinguished Name (DN) – pole

Formáty uložení certifikátů

• DER – binární formát (Distinguished Encoding Rules). Používá MS Outlook.
• PEM – Base64-kódovaný DER v ASCII. Preferovaný formát pro OpenSSL, Apache, Nginx.

Certifikační autority (CA)

• Root CA – kořenová CA s self-signed certifikátem (nemá nadřazenou CA). Zabudovaná v OS/prohlížečích.
• Intermediate CA – prostřední CA v řetězci.
• Certificate chain – server posílá svůj cert + chain certifikátů intermediátních CA.

Konfigurace SSL v Apache (klíčové direktivy)

• SSLEngine on – zapnutí SSL pro VirtualHost
• SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 – povolené verze
• SSLCipherSuite – seznam povolených šifer
• SSLCertificateFile – soubor s certifikátem (PEM)
• SSLCertificateKeyFile – soubor s privátním klíčem (PEM)
• SSLCertificateChainFile – řetězec CA certifikátů

Klientské certifikáty

• Alternativa k heslu – klient prokazuje identitu certifikátem podepsaným důvěryhodnou CA.
• SSLVerifyClient require – server vyžaduje certifikát od klienta.
• SSLCACertificateFile – CA, jejíž certifikáty klientů server akceptuje.

🌍 HTTP autentizace přes proxy a chunked encoding

HTTP Proxy autentizace

• Hlavička Proxy-Authorization: Basic base64(user:pass)
• Stejný mechanismus jako Basic autentizace – base64 kódování, nutno šifrovat přenos.

Chunked Transfer Encoding

• Vhodné pro: dynamicky generovaný obsah, streamování, přidávání trailerů.
• Každá HTTP/1.1 aplikace musí umět přijmout a dekódovat chunked encoding.
• Ukončení: blok s délkou 0 + prázdný řádek.
• Proxy server může chunky spojit do jedné odpovědi.

HTTP/1.1 200 OK
Transfer-Encoding: chunked

1a
abcdefghijklmnopqrstuvwxyz
0

📋 Shrnutí okruhu 2

Kontrolní otázky a odpovědi

• Q: Proč je HTTP bezestavový a co z toho plyne?
  A: Server nezpracovává každý požadavek v kontextu předchozích. Výhoda: jednoduchost a škálovatelnost. Nevýhoda: stav (přihlášení) musí spravovat aplikace přes cookies/sessions.
• Q: Jaký je rozdíl mezi 401 a 403?
  A: 401 Unauthorized = klient není autentizován (nemá přihlašovací údaje nebo jsou špatné). 403 Forbidden = klient je autentizován, ale nemá oprávnění k danému zdroji.
• Q: Co je chunked encoding a k čemu slouží?
  A: Způsob přenosu dat, kde server odesílá data po blocích s hexadecimální délkou každého bloku, bez nutnosti znát celkovou velikost předem. Vhodné pro dynamicky generovaný obsah.
• Q: Jak TLS chrání před Man-in-the-Middle útokem?
  A: Klient ověřuje certifikát serveru vůči důvěryhodným CA, kontroluje platnost a shodu CN/SAN s DNS jménem. Pokud útočník podstrčí jiný certifikát, klient ho odmítne (není podepsán důvěryhodnou CA).
• Q: Proč je Basic autentizace nebezpečná bez HTTPS?
  A: Přihlašovací údaje jsou kódovány base64 (reversibilní, ne šifrování). Kdokoli zachytí paket, snadno dekóduje heslo. Řešení: vždy HTTPS.

🔄 Životní cyklus zpracování požadavku

Každý příchozí HTTP požadavek prochází v Apache těmito fázemi (v pořadí):

1. Překlad URI → jméno souboru (WS → FS mapování) – Apache zjistí, který soubor na filesystému odpovídá URL. Ovlivňuje ho DocumentRoot, Alias, ScriptAlias, RewriteRule.
2. Kontrola přístupu – autentizace (kdo jsi?) + autorizace (smíš to?). Kontrola IP adres. Pokud selže → 401 nebo 403.
3. Zjištění MIME typu – podle přípony souboru (mod_mime) nebo obsahu (mod_mime_magic).
4. Fixups – doplňkové operace (co se nestihlo dříve).
5. Generování odpovědi (handler) – buď přímé odeslání souboru (statický obsah), nebo spuštění CGI/SSI/filtru (dynamický).
6. Zalogování – zápis záznamu do access logu.

📄 Statický obsah

Apache pro statický obsah:

• Nalezne soubor na FS podle DocumentRoot/Alias.
• Zjistí MIME typ (mod_mime – podle přípony; mod_mime_magic – podle obsahu).
• Nastaví hlavičky (Content-Type, Content-Length, Last-Modified, ETag).
• Odešle obsah souboru jako tělo odpovědi.

Výchozí stránka adresáře

• DirectoryIndex index.html index.htm index.php – hledá tyto soubory v adresáři.
• Options +Indexes – pokud index neexistuje, vygeneruje seznam obsahu adresáře (mod_autoindex). Nebezpečné ponechat na produkci!

MIME typy – konfigurace

• TypesConfig /etc/mime.types – globální databáze přípon→MIME
• AddType image/gif .gif – přidání vazby
• ForceType text/plain – vynucení MIME pro adresář
• DefaultType – od Apache 2.4 ignorováno
• Změna MIME typu nezmění Last-Modified – je třeba touch souboru pro reload cache.

⚡ Dynamický obsah – CGI

Jak CGI funguje

1. Klient požádá o URL, která je mapována na CGI skript (ScriptAlias nebo handler).
2. Server spustí skript jako nový proces.
3. Data od klienta (GET parametry, POST tělo) jsou předána přes proměnné prostředí a stdin.
4. Skript vygeneruje HTTP hlavičky + prázdný řádek + tělo a vypíše na stdout.
5. Server přepošle výstup klientovi.

Klíčové proměnné prostředí CGI

mod_cgi vs mod_cgid

• mod_cgi – procesové zpracování (prefork MPM). Interní mechanismus fork.
• mod_cgid – vláknové zpracování (worker/event MPM). Používá externího daemona přes socket (ScriptSock) pro fork nových procesů – replikace procesů s vlákny je nákladná.

🔀 Dynamický obsah – SSI (Server Side Includes)

Principy SSI

• Server prochází HTML soubor a hledá SSI direktivy ve formátu <!--#element attr=value -->.
• Mezi <!-- a #element nesmí být mezera!
• Zpracovává výstupní filtr INCLUDES (modul mod_include).

Klíčové SSI elementy

• <!--#include file="header.html" --> – vložení souboru
• <!--#include virtual="/cgi-bin/script.cgi" --> – vložení výstupu URL
• <!--#echo var="LAST_MODIFIED" --> – výpis proměnné
• <!--#exec cmd="/bin/date" --> – spuštění příkazu (vyžaduje Options +Includes, ne jen IncludesNoExec)
• <!--#config timefmt="%D" --> – nastavení formátu
• <!--#if expr --> ... <!--#endif --> – podmíněný obsah

Povolení SSI v konfiguraci

• Options +IncludesNoExec – SSI bez spouštění příkazů
• Options +Includes – SSI včetně exec
• Typicky s příponou .shtml: AddType text/html .shtml + AddOutputFilter INCLUDES .shtml

↩️ Přesměrování a přepisování URL

mod_alias – jednoduché přesměrování

• Redirect [status] /stara-url http://nova-url
• RedirectMatch (.*)\.htm$ http://example.com$1.html – s regulárním výrazem
• Stavové kódy: permanent (301), temp (302), seeother (303), gone (410)
• Výchozí: 302 (dočasné)
• Direktivy Redirect mají přednost před Alias a ScriptAlias.

mod_rewrite – podmíněné přepisování

• Libovolný počet pravidel a podmínek; řetězení pravidel.
• Přepisování: interní (URL → FS) nebo vnější (URL → URL).
• Pravidla se nedědí do podsekcí – nutno explicitně povolit.

RewriteEngine On
# Podmínka: spojení není HTTPS
RewriteCond %{HTTPS} !=on
# Pravidlo: přesměrovat /secure/* na HTTPS
RewriteRule ^/?secure/(.*) https://%{SERVER_NAME}/secure/$1 [R,L]

Přepisovací příznaky (flags)

• [R] / [R=301] – vnější přesměrování (redirect)
• [L] – poslední pravidlo (dál nezpracovávat)
• [NC] – case-insensitive porovnání
• [P] – přes proxy (implikuje [L])
• [F] – vrátí 403 Forbidden
• [C] – zřetězení s dalším pravidlem
• [QSA] – připojí původní query string

🔁 Proxy server v Apache

Forward proxy

• Klient posílá požadavky proxy serveru, ten je přeposílá dál.
• Použití: přístup z lokální sítě, anonymizace, filtrování, caching.
• Konfigurace: ProxyRequests On, zabezpečení <Proxy *> Require ip … </Proxy>
• Pozor: otevřený proxy server je bezpečnostní riziko!

Reverse proxy

• Klient si myslí, že komunikuje přímo se serverem, ale proxy přeposílá požadavky na backend.
• Použití: load balancing, SSL offloading, cache, skrytí backendů.
• ProxyPass /app http://backend.local:8080/ – mapování URL na backend
• ProxyPassReverse /app http://backend.local:8080/ – oprava Location hlaviček v odpovědích
• Pozor: ProxyPassReverse mění pouze hlavičky (Location, URI), ne obsah HTML stránek.

Load Balancing (mod_proxy_balancer)

• Rozložení zátěže mezi více backendových serverů.
• Algoritmy: byrequests (počet požadavků), bytraffic (objem dat), bybusyness (počet čekajících).
• Podpora sticky sessions (přiřazení klienta vždy ke stejnému backend).

<Proxy balancer://mycluster>
  BalancerMember http://web1.local loadfactor=1
  BalancerMember http://web2.local loadfactor=2
  ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass / balancer://mycluster/

🚦 Paralelní zpracování požadavků – principy

Webový server musí obsluhovat mnoho klientů souběžně. Apache to řeší volbou MPM:

Prefork – izolace procesů

• Master proces dopředu fork-uje spare workers (zásobník čekajících procesů).
• Každý příchozí požadavek obslouží jeden z připravených procesů.
• Počet procesů řízen direktivami: StartServers, MinSpareServers, MaxSpareServers, MaxClients.
• Výhoda: úplná izolace (chyba v jednom požadavku neovlivní ostatní).

Worker/Event – vlákna

• Procesy spravují vlákna; každé vlákno obsluhuje jeden požadavek.
• Výrazně nižší paměťová náročnost (vlákna sdílí paměť procesu).
• Event MPM navíc: separátní listener vlákno pro accept() a keep-alive správu.
• Konfigurace: ThreadsPerChild, MaxRequestWorkers, MaxConnectionsPerChild.

Caching (mod_cache)

• Ukládá odpovědi do paměti nebo na disk pro opakované požadavky.
• mod_cache_disk – uložení na disk (CacheRoot, CacheEnable disk /).
• Snižuje zátěž backendu, zkracuje dobu odpovědi.
• Respektuje HTTP cache hlavičky (Cache-Control, Expires, ETag, Last-Modified).

Dojednávání obsahu (Content Negotiation)

• Hlavičky: Accept, Accept-Language, Accept-Encoding, Accept-Charset
• Modul mod_negotiation, metody: Multiviews (volba dle přípon) nebo Type-map (.var soubor)
• Pokud žádná varianta nevyhovuje → 406 Not Acceptable
• Komprese: mod_deflate, AddOutputFilterByType DEFLATE text/html text/plain

📊 Logování a monitoring

Error log

• ErrorLog /var/log/apache2/error.log
• LogLevel error|warn|info|debug|trace1–8
• Obsahuje i ladící výstup CGI skriptů (stderr).

Access log (mod_log_config)

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /var/log/apache2/access.log common

mod_status – monitoring serveru

• Zobrazuje: počet worker vláken (working/idle), statistiky, aktuálně obsluhované požadavky, uptime, CPU.
• URL: /server-status, /server-status?refresh=5 (autorefresh), /server-status?auto (strojový výstup)
• Důležité: omezit přístup pouze z localhost/admin sítě!

📋 Shrnutí okruhu 3

Kontrolní otázky a odpovědi

• Q: Jaký je rozdíl mezi statickým a dynamickým obsahem z pohledu webového serveru?
  A: Statický obsah = server soubor pouze najde, přidá HTTP hlavičky a odešle. Dynamický obsah = server spustí program/skript (CGI) nebo zpracuje direktivy v souboru (SSI) a výsledek odešle. Dynamický je pomalejší, ale reaguje na data požadavku.
• Q: Jak CGI předává data od klienta skriptu?
  A: GET parametry přes env. proměnnou QUERY_STRING, POST data přes stdin (délka v CONTENT_LENGTH), HTTP hlavičky jako HTTP_* proměnné. Vstup je URL-encoded, skript musí dekódovat.
• Q: Jaký je rozdíl mezi Redirect a RewriteRule?
  A: Redirect (mod_alias) je jednoduché statické přesměrování klienta na novou URL. RewriteRule (mod_rewrite) umožňuje podmíněné a komplexní přepisy s regulárními výrazy, podmínkami, zachyceními skupin; může přepisovat interně (URL→soubor) nebo externě (redirect).
• Q: Proč je event MPM lepší než worker pro keep-alive spojení?
  A: Worker vlákno drží keep-alive spojení nečinně po celou dobu timeoutu. Event MPM předá otevřené spojení listener vláknu, worker se uvolní pro jiný požadavek – server tak obslouží více klientů se stejným počtem vláken.
• Q: Co je reverse proxy a k čemu se používá?
  A: Proxy server přijímající požadavky místo backendu. Klient neví o existenci backendů. Použití: load balancing (distribuce zátěže), SSL offloading (dekóduje HTTPS před backendami), caching (snižuje zátěž backendu), zabezpečení (backend schován za proxy).