성공과 실패를 결정하는 1%의 네트워크 원리
Chapter 1
1. HTTP Request Message 작성
(1) URL 입력
- 브라우저에서 URL을 입력하는 것으로 시작한다.
- URL(Uniform Resource Locator) : 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약
- URL 맨 앞에 있는 문자열은 엑세스 대상 프로토콜 종류를 의미한다.
ex) 웹서버는 http:, FTP서버는 ftp:, mailto:, file: 등
cf) HTTP(HyperText Transfer Protocol), FTP(File Transfer Protocol)
(2) URL 해독
- 브라우저가 처음 하는 일은 웹 서버에 보내는 리퀘스트 메시지 작성하기 위해 URL 해독하는 것
ex) http://www.google.com/dir1/file1.html
-> http: 웹서버 엑세스를 위한 프로토콜을 의미, //는 뒤에 이어지는 문자열이 서버이름임을 의미, www.google.com은 은 웹서버명을 의미, /dir1/file1.html은 은 데이터 출처(파일)의 경로명을 의미한다.
cf) 파일명 또는 디렉토리명 생략된 경우에는 /index.html 또는 /default.htm이라는 파일에 엑세스하는 것
- URL 예약 문자 : URL상에서 특정 기능을 하는 문자
? -> 파라미터가 시작된다는 것을 알려줌
= -> 파라미터 값 대입
& -> 다음 파라미터 식별자(and개념)
+ -> 공백으로 해석
# -> #뒤에 글자들 다 무시하기
- URL 인코딩 : 데이터 전송상에 손실을 막기위함, 예약문자를 단순 데이터로 전송위함(웹브라우저 사용할 경우 브라우저에서 자동으로 해줌)
& -> %26
% -> %25
+ -> %2B
공백 -> %20
= -> %3D
# -> %23
' -> %27
? -> %3F
(3) HTTP 이해
- HTTP 프로토콜은 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것
- Request Message : 리퀘스트 라인, 메시지 헤더, 메시지 본문으로 이루어짐
- 리퀘스트 라인 : <메소드>공백<URI>공백<HTTP 버전> -> 무엇을(URI), 어떻게(메소드)
- 메시지 헤더 : 리퀘스트의 부가적 정보, 메시지 본문 : 데이터(POST 메소드 사용시)
- 메소드 종류
| GET | 웹서버에 엑세스하여 페이지의 데이터를 읽을 때 사용, URI에 데이터를 저장한 파일 이름을 씀 |
| POST | 폼에 데이터를 사용하여 웹서버에 송신하는 경우 사용 |
- 메시지 헤더 필드 종류
| 제너럴 헤더 | Date | 리퀘스트나 응답이 작성된 날짜 |
| Connection | 응답송신후 TCP에 계속 접속할지, 연결을 끊을지를 나타냄 | |
| 리퀘스트 헤더 | Host | 리퀘스트 받는 서버의 IP주소와 포트번호 |
| 응답 헤더 | Server | 서버 소프트웨어의 명칭이나 버전 |
| 엔티티 헤더 | Content-Length | 메시지 본문의 길이 |
| Content-Type | 메시지 본문이 어떤 데이터인지 종류 | |
| Last-Modified | 정보를 최종 변경한 일시 |
- Response Message : <HTTP 버전>공백<스테이터스 코드>공백<응답 문구>
- HTTP 상태코드
| 1XX | 정보 |
| 2XX | 성공(200 : OK) |
| 3XX | 리다이렉션(302 : 다른 페이지로 이동) |
| 4XX | 클라이언트 에러(400 : 클라이언트 요청에러, 403 : 접근권한 없음, 404 : 존재하지 않음) |
| 5XX | 서버 에러 |
- 리퀘스트 메시지에 쓰는 URI는 하나뿐으로, 복수의 파일을 읽을 때는 웹서버에 별도의 리퀘스트 메시지를 보낸다.
- 웹서버는 단순히 한 개의 리퀘스트에 대한 한 개의 응답만 돌려보낸다.
- 페이지가 문장으로만 되어있는 것이 아니라 영상 등이 포함되어 있는 경우, 태그를 사용한다.
2. 웹 서버의 IP주소를 DNS서버에 조회
(1) IP주소
- 브라우저는 URL을 해독하거나 HTTP 메시지를 작성하지만, 메시지를 네트워크에 송출하는 기능은 없다. OS에 의뢰
- OS에 송신 의뢰할 때는 도메인명이 아니라 IP주소로 메시지 수신인를 지정해야 한다.
- TCP/IP : 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어지는 것, 서브넷이란 허브에 몇 대의 PC가 접속된 것으로 생각하기
- '00동 00번지' -> ~동에 해당하는 번호는 네트워크 번호, ~번지에 해당하는 번호는 호스트 번호, 두 개를 합쳐 IP주소
- IP주소 표기법
| IP주소 본체의 표기방법 | 10.11.12.13 |
| IP주소 본체와 같은 방법으로 네트워크 표기방법 | 10.11.12.13/255.255.255.0 (뒤에 붙은게 넷마스크) |
| 네트워크 번호의 비트 수로 넷마스크 표기방법 | 10.11.12.13/24 |
| 서브넷을 나타내는 주소 | 10.11.12.0/24 (호스트 번호 부분의 비트가 모두 0이면 서브넷 자체 의미) |
| 서브넷의 브로드캐스트를 나타내는 주소 | 10.11.12.255/24 |
ex) IP주소의 구조
10.1.2.3 -> 00001010.00000001.00000010.00000011
255.255.255.0 -> 11111111.11111111.11111111.00000000
<------------------------------><---------> 앞에는 네트워크 번호, 뒤에는 호스트 번호가 된다.
(2) Socket 라이브러리
- DNS(Domain Name System) : 서버명(도메인명)과 IP주소를 대응시키기 위해 사용
- DNS서버에 조회한다는 것은 DNS서버에 조회 메시지를 보내고, 반송되는 응답 메시지를 받는다는 것
- 이러한 DNS 원리를 사용하여 IP주소를 조사하는 것을 네임 리졸루션이라 하고, 이를 실행하는 것이 리졸버이다.
- Socket 라이브러리는 네트워크 기능을 호출하기 위한 프로그램의 부품집
(3) 리졸버(resolver)
- 도메인명에서 IP주소를 조사할 때 브라우저는 Socket 라이브러리의 리졸버를 이용한다.
- 리졸버는 OS 내부에 포함된 프로토콜 스택을 호출하여 DNS서버에 메시지 송신 동작을 의뢰한다. 리졸버도 네트워크에 대해 데이터 송수신 기능이 없기 때문
- DNS서버는 서버에 등록된 도메인명과 IP주소의 대응표를 조사하여 IP주소를 회답한다.
3. 프로토콜 스택에 메시지 송신을 의뢰
(1) 데이터 송수신 동작
- IP주소 조사했으면 IP주소의 상대에 메시지 송신하도록 OS 내부의 프로토콜 스택에 의뢰한다.
- OS 내부의 프로토콜 스택에 메시지 송신 동작 의뢰할 때는 Socket 라이브러리 프로그램 부품을 결정된 순번대로 호출
- 데이터 송수신 동작 : 소켓 생성 -> 서버측의 소켓에 파이프 연결 -> 데이터를 송수신 -> 파이프 분리하고 소켓말소
cf) Socket : 라이브러리, socket : 프로그램 부품, 소켓 : 파이프 양 끝에 있는 출입구
(2) 소켓 작성단계
- Socket 라이브러리의 socket이라는 프로그램 부품을 호출하면 소켓이 생긴다고 생각하기
- 소켓이 생기면 디스크립터라는 것이 돌아온다. 이는 번호표같은 것으로 이를 통해 소켓 식별한다.
(3) 접속단계
- Socket 라이브러리의 connect 프로그램 부품을 호출하면 프로토콜 스택이 접속 동작을 실행
- connect는 디스크립터, 서버 IP주소, 포트번호 입력한다.
- IP주소는 네트워크에 존재하는 각 컴퓨터를 식별하기 위해 각각에 서로 다른 값을 할당한 것, 디스크립터는 컴퓨터 한 대의 내부에서 소켓 식별하기 위함, 포트번호는 접속 상대측에서 소켓 식별하기 위함
(4) 메시지 송수신 단계
- Socket 라이브러리의 write 프로그램 부품 사용
- write는 디스크립터와 송신 데이터를 지정
- 서버로부터 온 수신 메시지 저장하기 위한 메모리 영역은 수신 버퍼라고 지정
(5) 연결 끊기
- 데이터 송수신 동작 끝나면 Socket 라이브러리의 close 프로그램 부품 호출하여 연결 끊는다. 이러면 파이프 분리되고 소켓 말소된다.
