인터넷의 역사부터 웹의 탄생, HTTP 와 REST 등, 우리가 현재의 웹을 이해하는데 필요한 것들만 정리 했습니다.
현업에 개신 개발자 분들은 다들 아시는 내용이겠지만, 정작 우리 주위엔 웹을 많이들 쓰고, 관련해서 일을 하면서도 웹의 내부에 대해서는 잘 모르고 있는 사람들이 많습니다.
웹의 기반기술을 제대로 아는것이, 우리가 좀더 웹을 진지하게 접근하는 것의 시작이라고 생각합니다.
웹 사이트의 빠른 로딩을 위한 프론트 엔드 최적화 기법과 더불어 알아두어야 할 HTTP 프로토콜 최적화를 언급하며, 최근 발표된 HTTP/3를 소개합니다.
HTTP/3는 "Hyper Text Transfer Protocol over QUIC"의 내용을 근간으로 UDP의 장점을 HTTP에 활용한 버전입니다.
HTTP/3를 알기 위해서는 QUIC에 대한 이해와 함께, 기존 버전인 HTTP/2에서 어떤 부분이 개선되었는지에 대한 이해가 동시에 필요합니다.
Chrome을 활용한 웹 성능 비교 예제들은 HTTP/3의 기술들을 빠르게 이해하는 데 도움이 될 것입니다.
인터넷의 역사부터 웹의 탄생, HTTP 와 REST 등, 우리가 현재의 웹을 이해하는데 필요한 것들만 정리 했습니다.
현업에 개신 개발자 분들은 다들 아시는 내용이겠지만, 정작 우리 주위엔 웹을 많이들 쓰고, 관련해서 일을 하면서도 웹의 내부에 대해서는 잘 모르고 있는 사람들이 많습니다.
웹의 기반기술을 제대로 아는것이, 우리가 좀더 웹을 진지하게 접근하는 것의 시작이라고 생각합니다.
웹 사이트의 빠른 로딩을 위한 프론트 엔드 최적화 기법과 더불어 알아두어야 할 HTTP 프로토콜 최적화를 언급하며, 최근 발표된 HTTP/3를 소개합니다.
HTTP/3는 "Hyper Text Transfer Protocol over QUIC"의 내용을 근간으로 UDP의 장점을 HTTP에 활용한 버전입니다.
HTTP/3를 알기 위해서는 QUIC에 대한 이해와 함께, 기존 버전인 HTTP/2에서 어떤 부분이 개선되었는지에 대한 이해가 동시에 필요합니다.
Chrome을 활용한 웹 성능 비교 예제들은 HTTP/3의 기술들을 빠르게 이해하는 데 도움이 될 것입니다.
RabbitMQ/ActiveMQ 와 같은 비동기 메시징 미들웨어를 이용하여 다량의 서버를 orchestration(command & control) 할 수 있는 mcollective에 대한 한글 ppt 자료입니다. 상세한 내용은 http://wiki.tunelinux.pe.kr/x/LQAy 를 참고하시면 됩니다.
‘CrushFTP’ 솔루션은 Unix, Linux, Windows, OSX 등 다양한 플랫폼에서 실행되는 매우 강력하고 사용하기 쉬운 파일 전송 및 공유를 위한 전문 SFTP 서버 솔루션입니다.
- SFTP, FTP, FTPS, HTTP, HTTPS 프로토콜 동시 지원
- 웹 브라우저를 통한 파일 전송, 목록 보기(트리, 썸네일) 등 제공
- 서버 현황 통합 대시보드 제공
- 로그 뷰어를 통한 실시간 서버 로그 내역 제공
- 서버 OS 계정과 관계없이 자체 사용자 계정 관리
- 패스워드 방식이 아닌 SSH Key 방식의 접속 지원
- 비정상 사용 패턴을 감지하여 자동 접속 차단 적용 지원
- 파일 업로드/다운로드 등의 이벤트에 따른 태스크 실행 지원
- PGP 키 생성 및 파일 업로드/전송 시 PGP 파일 암호화/복호화 지원
- 태스크 잡 구성을 통한 파일 전송 관련 액션 설정 지원
- 고가용성을 위한 HA 구성 지원
4. 진짜 웹 서버가 하는 일
1. Set up connection
- 클라이언트의 접속을 받아들이거나, 닫는다.
2. Receive request
- HTTP요청 메시지를 네트워크로 부터 읽어들인다.
3. Process request
- 요청 메시지를 해석하고 그에 따른 작업을 한다.
4. Access resource
- 메시지에서 지정한 리소스에 접근한다.
5. 진짜 웹 서버가 하는 일
5. Construct response
- 헤더를 포함한 HTTP 응답 메시지를 생성
6. Send response
- 응답을 클라이언트에게 돌려준다.
7. Log transaction
- 로그파일에 트렌잭션 완료에 대한 기록을 남긴다.
6.
7. Step1 : 클라이언트 커넥션 수락
- 새 커넥션 다루기
클라이언트가 웹 서버에 TCP커넥션 요청
웹 서버는 TCP커넥션에서 IP를 체크 후, 인가 기능 제공
- 클라이언트 호스트 명 식별
웹 서버는 reverse DNS를 사용, 접근 제어와 로깅 기능 제공
하지만 성능상의 문제로 1.3에서 기본으로 off
9. - ident를 통해 클라이언트 알아보기
서버가 identd서버 포트(113)으로 정보 요청, 클라이언트는 클라이언트 정보를
돌려줌.
하지만 공공인터넷에서는 보안과, 트랜잭션 문제로 제한적인 사용.
Step1 : 클라이언트 커넥션 수락
10. 요청 메세지 파싱 방법
- 요청 메서드, 리소스 식별자(URI), 버전번호를 찾는다.
각 값은 한 개의 스페이스로 분리, 끝은 CRLF
- 메시지 헤더들을 읽는다. 끝은 CRLF
- 요청 본문이 있다면, Content-Length만큼 읽어 들인다.
Step2 : 요청 메시지 수신
11. 커넥션 입력/출력 처리 아케텍처
고성능 웹 서버는 수천 개의 커넥션을 동시지원
웹 서버의 아키텍처에 따라 요청을 처리하는 방식도 달라짐
Step2 : 요청 메시지 수신
12.
13. - 한 번에 하나씩 요청을 처리합니다.
- 트랜잭션이 완료되면, 다음 트랜잭션 처리
- 처리 도중에 모든 다른 커넥션이 무시 되기 때문에,
로드가 적은 서버에서 사용
단일 스레드 웹 서버
14. - 요청을 처리하기 위해, 여러개의 프로세스 혹은 고효율 스레드 할당.
- 단일 스레드 보다 많은 커넥션을 동시에 처리 가능
- 스레드/프로세스는 요청시 생성하거나, worker pool에서 사용
- 많은 요청으로 인한 메모리,시스템 리소스 소비가 이어진다.
그래서 스레드/프로세스 최대 생성 개수 제한을 둠
멀티프로세스와 멀티스레드 웹 서버
15. - 대량의 커넥션을 지원하기 위해 사용됨
- 모든 커넥션을 모니터링, 커넥션에 상태가 바뀌면 해당 커넥션 처리
- 스레드와, 프로세스는 유휴(idle) 상태의 커넥션에
매어있지 않아도 됨.
다중 I/O서버
16. - 여러개의 CPU의 이점을 살리기 위해, 멀티스레딩과 다중화를 결합한 모델
- 여러개의 스레드가 각각 열려있는 커넥션을 감시하고
변화가 있을때 커넥션에 대한 작업을 수행
다중 멀티스레드 웹 서버
17. Step3 : 요청처리
- 웹 서버가 요청을 받으면, 서버는 요청으로 부터 메서드, 리소스, 헤더, 본문
을
얻어서 요청을 처리한다.
- 메서드에 따라, 본문필요 여부 다름
- 이후 책의 나머지 챕터에서 다룸
18. Step4 : 리소스의 매핑과 접근
- 웹 서버는 리소스 서버
- 정적 파일(HTML, JPEG, JS), 동적 컨텐츠 제공
- URI에 매핑되는 리소스 식별 방법 제공
- Docroot(DocumentRoot)
- VirtualHost
- Directory Index
- 접근제어
21. DirectoryIndex
- 웹 서버는, 파일이름이 아닌 디렉토리 URL에 대한 요청을 받을 수 있다.
- 대부분의 웹 서버는 아래와 같이 처리
- 에러를 반환
- 디렉터리 대신 ‘색인 파일' 반환
- 디렉터리를 탐색, 내용을 담음 HTML반환
- 불필요한 파일 노출을 야기
22. Step5 : 응답 만들기
- 응답 메시지는 응답상태코드, 응답 헤더, 응답 본문(선택)으로 구성
- 응답 본문이 있다면, 응답 메시지는 다음을 포함한다.
- MIME타입을 서술하는 Content-Type헤더
- 길이를 서술하는 Content-Length헤더
- 실제 응답 본문의 내용
- 리다이렉션
23. MIME 타입 결정하기
웹 서버에게는 응답 본문의 MIME타입을 결정해야하는 책임이 있다.
- Mime.types
- 매직 타이핑(Magic typing)
- 유형 명시(Explicit typing)
- 유형 협상(Type negotiation)
24.
25. Step6 : 응답 보내기
- 전송과 응답도 커넥션 관리가 핵심
- nonpersistent(비지속) 커넥션
- 메세지 전송 후 커덱션을 닫기
- persistent(지속) 커넥션이라면
- 서버가 Content-Length헤더를 바르게 계산하기 위해 커넥션을 유지
- 클라이언트가 응답이 언제 끝나는지 알 수 없을경우 커넥션을 유지