[정글] Week07 - Web Server
Web Server 구현
나만의 웹서버를 만들어보기! (프록시 서버까지)
소켓이 무엇인지 공부해봅니다.
소켓을 이용하여, 요청과 응답을 하는 간단한 클라이언트/서버를 만들어봅니다.
HTTP 프로토콜를 이해하고, 클라이언트의 request를 받고, response를 내어주는 웹서버를 만들어봅니다.
- 웹서버는 어떤 기능들의 모음일까요?
'컴퓨터 시스템' 교재의 11장을 보면서 차근 차근 만들어주세요.(기본 코드는 모두 있습니다!)
웹 서버를 완성했으면 프록시(proxy) 서버 과제에 도전합니다.
http://csapp.cs.cmu.edu/3e/proxylab.pdf (출처: CMU 카네기멜론)
주요기능
브라우저와 웹서버 사이의 중간에 위치 (브라우저 - 웹프록시 - 웹서버)
브라우저는 프록시에 접속하고, 브라우저의 요청을 웹서버로 포워딩(전달)
웹서버가 프록시에 응답하면, 프록시는 브라우저에 응답을 전달
과제
1. 순차적 요청 처리
2. 병렬적 요청 처리
3. 요청 캐시
https://github.com/krafton-jungle/webproxy-lab 의 내용대로 진행합니다.
진행방법
1. 책에 있는 코드를 기반으로, tiny 웹서버를 완성하기 (tiny/tiny.c, tiny/cgi-bin/adder.c 완성)
2. AWS 혹은 container 사용시 외부로 포트 여는 것을 잊지 말기
3. 숙제 문제 풀기 (11.6c, 7, 9, 10, 11)
4. 프록시 과제 도전 (proxy.c 완성)
GOAL
소켓이해 → 에코서버 → tiny 웹서버를 만들고 → 숙제문제 11.6c, 7, 9, 10, 11 중 세문제 이상 풀기 → 프록시 과제 도전
HTTP 표준명세서
- HTTP/1.0 표준: RFC-1945
- Media (MIME) type
- HTTP/1.1 표준: RFC-7230 ~ 7240 (RFC-2616은 obsolete 됨)
- HTTP/2 표준: RFC-7540
- HTTP/3
- 표준안(34차): draft-ietf-quic-http-34
- 현재 구현 상황: Wikipedia
- 초간단 설명 (25년 이상 안 바뀜)
- TCP/IP : network layer, TCP 위의 HTTP, TCP 옆의 UDP
- Sockets : the low level endpoint used for processing information across a network
- Server:
- Create a socket with the socket()
- Bind the socket to an address using the bind()
- Listen for connections with the listen()
- Accept a connection with the accept()
- To send and receive data, use the write() and read()
- Client:
- Create a socket with the socket()
- Connect the socket to the address of the server using the connect()
- To send and receive data, use the write() and read()
- [요약]
- 서버와 클라이언트의 통신 (CS:APP 그림 11.12)
- 서버쪽
- socket() : 연결 통로 준비
- bind() : 특정IP와 연결
- listen() : 연결 후 요청을 기다리기
- accept() : read/write 또는 receive/send 메소드를 짝으로 사용하여 요청/응답 처리. 단, listen()에서의 스레드와 다른 스레드를 만들어 진행한다.
→ 스레드 분리 이유: 서버는 여러 요청을 받아야 하기에, listen() 스레드는(母) 놔두고 계속 기다리게 하고, accept() 스레드는 (子) 요청을 처리하도록 만들어 둠
→ 단, 우리 과제에서는 멀티프로세싱까지 다루지는 않음
- 클라이언트
- socket() : 연결 통로 준비
- connect() : 연결. 끝. 스레드 분리하지 않음
- 서버쪽
- HTTP / TCP / IP 통신 등
- IP 위에 → TCP 위에 → HTTP 가 있음. 모두 P. 즉 protocol. 규약=약속
→ Physical 레이어에 가까울 수록 밑에 있다고 표현 - IP단으로 갈 수록 하드웨어 환경(와이파이, LTE, 랜선, ...) 레이어를 나눠서 설계하는 이유는, 각 단계 별 환경이 변할 수 있고, 다양한 이종의 장치들이 나올 수 있기 때문
→ 한번에 설계하면 다 바꿔야 하니까, 레이어를 나눠서 약속을 정해둔 것 - TCP는 패킷 받는 게 보장됨 vs UDP는 패킷 받는 게 보장 안됨. 그냥 쏘는 것
→ 요새 동영상 스트리밍 같은 곳에 UDP 많이 씀. 중간에 화질 저하돼도 보는 데 문제 없으니까
→ 참고로 11장은 TCP 소켓으로 만들어지게 되어 있음. 2kb를 주면 2kb를 받는 구조. - HTTP가 처음 나왔을 때 뜬 이유: 사람이 읽을 수 있어서
- IP 위에 → TCP 위에 → HTTP 가 있음. 모두 P. 즉 protocol. 규약=약속
- 서버와 클라이언트의 통신 (CS:APP 그림 11.12)
공부 키워드
1. 네트워크 계층 (OSI7 Layer, TCP/ IP Layer)
2. 클라이언트-서버 모델
3. 소켓 (Socket, bind, listen, accept, connect, close)
4. 파일 디스크립터
5. Datagram Socket VS Stream Socket
6. CGI/ WebServer/ MIME Type
7. HTTP (요청/ 응답/ 메소드/ 상태 코드/ HEAD 메소드)
8. Proxy
1. 네트워크 계층 (OSI7 Layer, TCP/ IP Layer)
| OSI - Open Systems Interconnection 모든 유형의 네트워크 통신을 캡슐화한 개념적인 프레임워크 | |
| Physical Layer | 하드웨어 전송, 물리적 채널 ex. 랜선, 광섬유 케이블, 구리 케이블 |
| Data-Link Layer | 데이터 프레임 관리, CRC 기반의 오류 제어와 흐름 제어, Ethernet, MAC/ LLC |
| Network Layer | 노드를 거치는 경로를 찾아주는 역할, QoS 제공, IPv4/ IPv6 |
| Transport Layer | 두 기기 간의 종단 간 통신 담당, 흐름 제어 및 오류 제어, TCP/ UDP |
| Session Layer | 일대일 어플리케이션 연결 및 동기화 충돌의 시작과 끝을 관리, NFS/ SMB |
| Presentation Layer | 데이터 준비, 변환, 암호화, 압축, HTML/ JSON/ CSV |
| Application Layer | 사용자의 데이터와 직접 상호 작용, HTTPS/ POP3/ SMTP |
TCP/ IP Layer
| TCP/ IP Layer | 네트워크 통신을 구조화한 계층적 아키텍처 모델 |
| Network Access/ Interface Layer | Physical + Data-Link Layer, 역할 물리적 기능 수행, 데이터 단위 Frame, 전송 주소 MAC |
| Internet Layer | Network Layer, 역할 패킷 전송, 데이터 단위 Packet, 전송 주소 IP |
| Transport Layer | Transport Layer, 역할 논리적 통신 수행, 데이터 단위 Segment, 전송 주소 Port |
| Application Layer | 역할 응용 프로그램들이 네트워크 서비스를 사용할 수 있게 한다, 데이터 단위 Data/ Message |
OSI 7 Layer 와 TCP/ IP Layer 의 차이점은
OSI 7 Layer 는 이론적 모델이고, TCP/ IP 는 실전적 모델이다
2. 클라이언트-서버 모델 Client-Server Model
클라이언트 Client - 서비스를 사용하는 사용자 or 사용자의 단말기
서버 Server - 서비스를 제공하는 컴퓨터
Client-Server Model 은 클라이언트와 서버 간의 작업을 분리해주는 분산 어플리케이션 구조이자 네트워크 아키텍처
클라이언트와 서버가 각자의 역할에 맞게 구성되어 있는 구조
클라이언트는 서비스를 요청하는 주체이고 서버는 서비스를 제공하는 주체다
* 클라 A → 서버 A → 서버 B 일 때
클라이언트 : 클라 A, 서버 A
서버 : 서버 A, 서버 B
서버는 한 번에 여러 클라이언트에게 서비스를 제공할 수 있다.
3. 소켓
데이터를 주고 받기 위한 창구
소통의 종단점 (Endpoint)
Protocol, IP Address, Port Number 로 정의된다
소켓 통신의 흐름
Server - Client Socket 의 연결 요청을 대기하고, 연결 요청이 오면 새로운 소켓을 생성하여 통신이 가능하게 한다
1) socket() 함수로 소켓을 생성
2) bind() 함수로 생성된 소켓에 IP Address 와 Port Number 설정 (이 시점에서 소통 불가)
3) listen() 함수로 Client 연결 요청을 수신할 준비, 대기열을 설정하여 동시에 처리할 수 있는 Client 수 제한
4) accpet() 함수로 Client 연결 요청을 수락하면, Client 와 데이터를 주고 받을 수 있는 새로운 소켓 생성
+ 연결 대기 큐에서 첫번째 연결 요청을 가져오고, 새로운 소켓을 생성해서 실제 통신에 사용, 원래 소켓은 새로운 연결 요청 대기
5) send()/ recv() 함수로 데이터 송수신
6) close() 소켓 닫기 + 생성된 소켓을 종료하고 파일 디스크립터를 반납하는 역할도 한다
+ 만약 Close 함수를 통해서 소켓을 닫지 않으면 자원 누수/ 파일 디스크립터 고갈
Client
1) socket() 함수로 소켓 생성
2) connect() 함수로 서버에 연결 요청, 연결 성공 시 데이터 송수신 가능
3) 서버에서 accept() 를 받아 연결이 되면 send()/ recv() 로 데이터 송수신
4) close() 소켓 닫기, 서버에 EOF 전달
HTTP 통신과 소켓 통신의 차이
| HTTP 통신 | Socket 통신 |
| 클라이언트의 요청이 있을 때만 서버가 응답 | 클라이언트와 서버가 특정 포트를 통해 양방향 통신을 하는 방식 |
| JSON, HTML, Image 등 다양한 데이터 주고 받을 수 있음 | 데이터 전달 후 계속 연결 유지 (HTTP에 비해 많은 리소스 소모) |
| 서버 응답 후 연결을 바로 종료 but Keep Alive 일정 시간 커넥션 유지 | 실시간으로 데이터를 주고 받아야 하는 경우에 유리 |
| 데이터 전달이 필요한 경우에 유리 | 실시간 동영상 스트리밍이나 온라인 게임 등에 사용 |
4. 파일 디스크립터 File Descriptor
Linux or Unix 쪽의 시스템으로부터 할당 받은 파일을 대표하는 음이 아닌 정수 값
프로세스에서 열린 파일의 목록을 관리하는 테이블의 정수형 인덱스
프로세스가 실행 중에 파일을 Open 하면 커널은 해당 프로세스의 파일 디스크립터 FD 숫자 중 제일 작은 값을 할당해준다
그 프로세스가 열려 있는 파일에 시스템 콜을 이용해서 접근할 때, 파일 디스크립터 값을 이용해서 파일을 지칭할 수 있다
| 파일디스크립터 | 목적 | POSIX | stdio 스트림 |
| 0 | 표준 입력 | STDIN_FILENO | stdin |
| 1 | 표준 출력 | STDOUT-FILENO | stdout |
| 2 | 표준 에러 | STDERR_FILENO | stderr |
파일 디스크 립터 open 함수
open(pathname, flags, mode) // return fd
5. Datagram Socket VS Stream Socket
| Datagram Socket | Stream Socket |
| UDP를 사용하므로 비연결형 Connectionless 소켓 | TCP를 사용하므로 연결 지향형 Connection-Oriented 소켓 |
| 신뢰성을 보장할 수 없다 | 신뢰성을 보장한다 |
| 순서대로 송수신될지 보장하지 못 한다 | 데이터 순서대로 송수신을 보장한다 |
| 일대다 연결 가능 | 점대점 Point-to-point 연결 가능 |
| ex. 비디오 스트리밍 | ex. 파일 전송 |
6-1. CGI Common Gateway Interface
서버와 어플리케이션 간에 데이터를 주고 받는 방식 또는 컨벤션
웹 서버가 사용자 요청을 받아서 다른 정보 소스와 통신하게 해주는 일종의 다리 역할을 한다
예를 들어, 사용자가 웹사이트에서 검색 버튼을 선택하면, CGI 플그램이 사용자 요청 (검색어) 를 받아서
데이터베이스에 질의한 후, 그 결과를 다시 웹페이지에 표시하는 과정이 이루어진다
CGI 는 웹 서버가 다양한 정보 소스와 통신할 수 있게 해주는 일종의 규칙이다
CGI 주요 특징
1) 서버에서 실행
2) 재사용 가능한 코드
3) 표준화, 대부분의 최신 브라우저가 CGI 지원
4) 다양한 프로그래밍 언어 지원, C, C++, Java, PERL 등
5) 운영체제 독립적
6) 요청과 응답 처리
7) 서버 보안 권한으로 실행
🐣 왜 CGI 가 필요했는가? -> 처음에는 정적 컨텐츠만 사용 가능했음, 동적 컨텐츠 (사용자 상호 작용, DB 연동, 실시간 데이터 처리 등) 추가하기 위해 필요해짐
6-2. Web Server
HTTP or HTTPS 를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트를 전송해 주는 서비스 프로그램
웹 페이지를 클라이언트로 전달하고, 클라이언트로부터 콘텐츠를 전달 받는다 (파일 업로드, 웹 폼 수신 등)
대표적인 웹 서버 - Apache, Tomcat,
6-3. MIME Multipurpose Internet Mail Extensions
서버가 클라이언트에게 파일의 형식 (ex. 텍스트, 이미지, 비디오 등) 을 알려주는 방식
웹 서버는 MIME 타입을 통해 클라이언트가 파일의 형식을 알 수 있게 하고, 클라이언트는 이를 기반으로 알맞게 표시한다
CGI 프로그램이 실행된 후 결과를 출력할 때도 MIME 타입이 중요하게 사용된다
+ HTTP 미디어 형식 (Media Type) - Content-Type 및 Accept 헤더 필드의 인터넷 미디어 형식을 사용
media-type = type "/" subtype *(";" parameter)
type = token
subtype = token
세 가지 요소의 관계 - CGI, Web Server, MIME
웹 서버는 클라이언트 요청을 처리하고, 필요한 경우 CGI 프로그램을 실행해 동적 컨텐츠를 생성한다
이 때 CGI 프로그램은 응답 헤더에 올바른 MIME 타입을 설정해 클라이언트가 응답 데이터를 정확히 해석할 수 있게 돕는다
7. HTTP (요청/ 응답/ 메소드/ 상태 코드/ HEAD 메소드)
헤더 - Key: vlaue 쌍에 저장된 텍스트 정보
| HTTP HyperText Transfer Protocol, 웹 서버/ 웹 브라우저 상호 간의 데이터 전송을 위한 어플리케이션 계층 프로토콜 | |
| HTTP 요청 | 클라이언트가 서버에 특정 리소스 요청/ 요청 라인 + Header + Body |
| HTTP 메소드 | GET, POST, PUT, DELETE, CONNECT, LINK 등 |
| HTTP 응답 | 서버가 클라이언트의 요청에 대한 결과 반환/ 상태 라인 + Header + Body |
| HTTP 상태 코드 | 숫자를 통해 상태 제공, 1XX 정보 제공, 2XX 성공, 3XX 리디렉션, 4XX 클라이언트 오류, 5XX 서버 오류 |
HEAD METHOD - 리소스를 GET 메서드로 요청했을 때 응답으로 오는 헤더 부분만 요청하는 메소드
응답엔 본문 (Body 부분) 을 가져선 안 되며, 본문이 존재하더라도 무시해야 한다
이렇게 Header 부분만 요청하는 HEAD 메소드를 사용하는 이유는, HEAD 메소드는 종종 Caching 을 사용하는 클라이언트가 가장 최근에 접속한 이후로 Document 가 바뀌었는지를 보기 위해 사용한다, 데이터 양이 줄어서 빠르게 서버의 상태를 조회할 수 있다
+ GET Method - 서버로부터 데이터를 조회할 때 사용, 주로 URL 에 쿼리스트링을 포함해 요청
+ POST Method - 데이터를 서버에 제출할 때 사용하며, 주로 폼 데이터를 전송할 때 적합
GET 은 캐싱이 가능하지만 POST 는 데이터를 포함해 전송하므로 캐싱되지 않는다
8. Proxy
다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는 중간 프로그램
클라이언트와 서버 사이에 존재하며, 중계기로서 대리로 통신을 수행하는 것을 Proxy 라고 하며,
그 중계 기능을 하는 주체를 Proxy Server 라고 한다
Proxy Server 역할
1) 요청 및 응답 필터링 - 클라이언트와 서버 간의 데이터 흐름을 제어하고 불필요한 요청 차단
2) 캐싱 - 자주 요청되는 데이터를 저장하여 서버의 부하를 줄이고 응답 시간 단축
3) 보안 - 클라이언트의 IP 주소를 숨기거나, SSL 터널링 등을 통해 데이터의 안정성 향상
4) 접근 제어 - 특정 웹사이트에 대한 접근을 제한하거나, 사용자의 활동을 모니터링하는 데 사용
5) 로그 기록, 관리 - 서버 측에서는 프록시 서버의 기록이 있고, 프록시 서버에게는 클라이언트의 기록이 남아 있다
어떤 IP 에서 어떤 IP 로 얼마나 접속해 있는지 확인하거나, 특정 IP 가 방문할 수 있는 웹사이트를 제한할 수 있다