Home
About
- Ara Jo
  
  Aspiring Backend Developer :)
- Learn More
- Email
- Github
Posts
- All Posts
- All Tags
Projects

Book/성공과 실패를 결정하는 1% 네트워크 원리/1장

31 Aug 2021

Reading time ~4 minutes

1. HTTP 리퀘스트 메시지를 작성한다

1. URL 입력

모든 URL의 맨 앞에 (http:, ftp:, file:, mailto:)와 같은 액세스 방법을 나타내는 문자열이 붙음
http : 액세스 대상이 웹 서버, HTTP 프로토콜 사용
ftp : 엑세스 대상이 FTP 서버, FTP 프로토콜 사용

2. URL 해독

URL의 요소 (ex. http://www.lab.cyber.co.kr/dir1/file1.html)

http: + // + 웹 서버명 + / + 디렉토리명 + / + … + 파일명

3. 파일명 생략한 경우

http://www.lab.cyber.co.kr/dir/ : 끝에 디렉토리명 다음 파일명을 생략하고 / 로 끝난 경우, 미;리 서버측에 설정해둔 기본 파일명으로 엑세스 (index.html, default.htm)
http://www.lab.cyber.co.kr/ : 끝에 / 가 있으므로 / 라는 디렉토리의 기본 파일에 엑세스
http://www.lab.cyber.co.kr : 끝에 / 까지 모두 생략된 경우, 루트 디렉토리 아래의 기본 파일에 엑세스
http://www.lab.cyber.co.kr/whatisthis : 끝에 / 가 없으므로 파일명으로 보는 것이 맞지만 이런 경우 웹서버에 해당 파일이 있으면 파일명으로, 해당 디렉토리가 있으면 디렉토리로 간주

4. HTTP의 기본 개념

HTTP 프로토콜 : 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것
URI : 리퀘스트 메시지 안의 무엇을 에 해당, /index.html
메서드 : 리퀘스트 메시지 안의 어떻게 에 해당, GET, POST
- GET : 웹 서버에 엑세스하여 페이지의 데이터를 읽을 때 사용
- POST : 폼에 데이터를 사용해서 웹 서버에 송신하는 경우 사용
Status code : 실행 결과를 나타내는 코드, 404 Not Found

5. HTTP Request

Request Line : 리퀘스트 메시지의 첫 번째 행 GET /index.html HTTP/1.1 (메서드, URI, HTTP버전)
Message Header : 리퀘스트 메시지의 두 번째 행부터 이어지는 내용(날짜, 데이터의 종류, 언어, 압축 형식, 버전, 데이터 유효기간 등 다수의 항목 포함)
메시지 본문 : 메시지 헤더 뒤 공백 행 다음 이어지는 내용, POST일 때만 포함 (송신할 데이터)

6. HTTP Response

Status Line : 실행 결과를 나타내는 Status code와 Status Message 포함
Message Header

리퀘스트 메시지에 쓰는 URI는 하나뿐으로, 복수의 파일을 읽어올 때는 웹 서버에 별도의 리퀘스트 메시지를 보낸다.

2. 웹 서버의 IP 주소를 DNS 서버에 조회한다

1. IP주소의 기본

IP주소 = 네트워크 번호 + 호스트 번호
Network/네트워크계층/IP주소와 서브넷

2. 도메인명과 IP주소를 구분하여 사용하는 이유

숫자로 된 IP주소를 기억하기 어려우므로 서버의 이름을 도메인으로 사용
도메인명을 IP주소 대신 사용하면 실행 효율이 떨어짐
⇒ 사람은 이름을 사용하고, 라우터는 IP주소를 사용하는 방법으로 결정!

3. Socket 라이브러리가 IP주소를 찾는 기능을 제공한다

DNS 서버에 도메인에 해당하는 IP 주소를 알려달라고 요청해서 IP 주소를 찾음
네임 리졸루션 : DNS의 원리를 사용하여 IP 주소를 조사하는 것
리졸버 : 리졸루션을 실행하는 것, DNS 클라이언트에 해당

3. 전 세계의 DNS 서버가 연대한다

1. DNS 서버의 기본 동작

클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일
조회 메시지 : 이름 + 클래스 + 타입
DNS 서버는 등록된 정보를 찾아서 이름, 클래스, 타입의 세 가지가 일치하는 것을 찾아 해당하는 IP 주소를 클라이언트에게 회답

DNS 서버는 서버에 등록된 도메인명과 IP주소의 대응표를 조사하여 IP주소를 회답

2. 도메인의 계층

정보를 전부 한 대의 DNS 서버에 등록할 수 없으므로 정보를 분산시켜 다수의 DNS 서버에 등록하고 다수의 DNS 서버가 연대하여 어디에 정보가 등록되어 있는지를 찾아내는 구조
도메인과 도메인명 : www.cyber.com com 이라는 도메인 아래에 cyber라는 도메인이 있고 그 안에 www라는 이름이 있음

3. 담당 DNS 서버를 찾아 IP 주소를 가져온다

액세스 대상의 웹 서버가 어느 DNS 서버에 등록되어 있는지 찾아내는 방법
하위의 도메인을 담당하는 DNS 서버의 IP 주소를 상위의 DNS 서버에 등록 > 상위의 DNS 서버를 또 그 상위의 DNS 서버에 등록하는 식으로 차례대로 등록
⇒ 상위의 DNS 서버에 가면 하위의 DNS 서버의 IP 주소를 알 수 있고, 조회 메시지를 보낼 수 있음
최상위 도메인(com, kr)은 루트 도메인 DNS 서버에 등록하고 루트 도메인의 DNS 서버를 인터넷에 존재하는 DNS 서버에 전부 등록
클라이언트에서 어딘가의 DNS 서버에 엑세스하면 여기에서부터 루트 도메인을 경유하여 도메인의 계층 아래로 찾아가 최종적으로 원하는 DNS 서버에 도착

4. DNS 서버는 캐시 기능으로 빠르게 회답할 수 있다

DNS 서버는 한 번 조사한 이름을 캐시에 기록 ⇒ 루트 도메인부터 찾기 시작하는 것보다 더 편리
조회한 이름이 등록되어 있지 않은 경우도 캐싱해서 빠르게 회답가능
주의 : 캐시 안 정보는 반드시 올바르다고 단언할 수 없으므로 데이터의 유효 기간이 지나면 캐시에서 삭제하고 회답 시 캐싱된 정보인지 조회된 정보인지 명시

4. 프로토콜 스택에 메시지 송신을 의뢰한다

1. 데이터 송수신 동작의 개요

데이터 송수신은 파이프와 같음 : 한쪽 끝에서 파이프에 데이터를 쏟아부으면 파이프를 통해 반대쪽에 도착하고 양방향으로 데이터를 보낼 수 있음
송수신 동작을 하기 전 둘 사이를 파이프로 연결하는 동작이 필요함
소켓 : 데이터의 출입구, 파이프의 양 끝
- 먼저 서버측에서 소켓을 만들고 소켓에 클라이언트가 파이프를 연결하기를 기다림
- 클라이언트측에도 소켓을 만들고 소켓에서 파이프를 늘려 서버측의 소켓에 연결
데이터를 전부 보내고 나면 파이프가 분리됨
파이프의 연결 : 클라이언트측 > 서버측
파이프의 분리 : 어느 쪽에서 분리해도 상관없음
과정

소켓을 만든다 (소켓 작성 단계)
서버측의 소켓에 파이프를 연결한다 (접속 단계)
데이터를 송수신한다 (송수신 단계)
파이프를 분리하고 소켓을 말소한다 (연결 끊기 단계)

위의 동작을 실행하는 것은 OS 내부의 프로토콜 스택

2. 소켓의 작성 단계

Socket 라이브러리의 socket 메서드를 호출하여 소켓을 만듦
소켓이 생기면 디스크립터라는 것이 반환되고 애플리케이션은 이것을 메모리에 기록
디스크립터 : 소켓을 식별하기 위해 사용 (여러 개의 창이 열려있을 때 구분하기 위한 용도)

3. 파이프를 연결하는 접속 단계

Socket 라이브러리의 connect 메서드를 호출하여 서버측 소켓에 연결
- 디스크립터 : 애플리케이션이 소켓을 식별하는 것
- 서버의 IP주소, 포트 번호 : 클라이언트와 서버 간에 상대의 소켓을 식별하는 것

4. 메시지를 주고받는 송수신 단계

Socket 라이브러리의 write 메서드를 호출하여 데이터 송신
Socket 라이브러리의 read 메서드를 호출하여 데이터 수신

5. 연결 끊기 단계에서 송수신이 종료된다

Socket 라이브러리의 close 메서드를 사용하여 연결 끊기

csstudy network book Share Tweet +1