HTTP와 네트워크

kiwonkim·2021년 5월 29일

네트워크란?

PC와 같은 노드가 그물망 처럼 연결된 통신 형태.
네트워크를 이용해 타 PC와 데이터의 교환이 가능해짐.

OSI 7계층

응용 계층 : 우리가 사용하는 응용 프로그램.
표현 계층 : 데이터 표현 차이 해결. 인코딩, 암호화, 복호화 수행.
세션 계층 : 통신장치간 상호작용을 위한 세션 생성.
전송 계층 : 종단간 신뢰성 있고 정확한 데이터 전송 담당. 포트번호.
네트워크 계층 : 데이터를 수신자까지 보내는 최적의 경로 설정(라우팅). IP주소.
데이터 링크 계층 : 물리적으로 연결된 노드간 데이터 전송 제공 및 오류 수정. MAC주소.
물리 계층 : 데이터를 전기적 신호로 변경하여 통신 케이블로 전송.

포트번호 : 송/수신 응용프로그램 식별.
IP주소 : 네트워크에서 각 노드에 부여된 식별주소.
MAC주소 : 물리적으로 연결된 노드 내에서 특정 PC 식별하는 주소.

송신자 - 5,6,7 계층의 데이터를 베이스로, 내려오면서 TCP/UDP, IP, 이더넷 헤더를 각각 붙이며 캡슐화 진행 후 최종적으로 전기 신호로 바꿔 전송.

수신자 - 물리 계층에서 수신한 전기 신호를 계층을 올라가며 역캡슐화 진행하여 5,6,7 계층으로 전달.

Web에서의 네트워크

URI와 URL

URI란?
네트워크 상에서 리소스(파일 등)를 식별하기 위한 문자열.

URL란?
네트워크 상에서 리소스의 위치를 나타내는 문자열.
HTTP에서는 클라이언트가 서버에게 request 할때 사용한다.
ex) http://127.0.0.1:80/dir/index.html?id=1

http:// - 사용하는 프로토콜.
127.0.0.1 - 서버의 주소.
:80 - 서버의 포트 번호.
/dir/index.html - 원하는 파일 경로
?id - 쿼리 문자열. url을 통해 서버에게 넘겨주는 정보. GET방식.

URL 입력시 일어나는일.

www.naver.com/index.html 입력했다고 가정.
(www.naver.com 의 index.html 파일을 보고싶어)

클라이언트는 DNS서버에 www.naver.com 의 IP주소 질의
DNS서버는 IP주소 알려줌
클라이언트의 HTTP는 IP주소(웹서버)에 보낼 HTTP 메시지 작성. (www.naver.com/index.html의 리소스좀 보내주세요)
클라이언트의 TCP 담당은 통신하기 쉽도록 단편화.
IP 담당은 라우팅 알고리즘으로 최선의 경로 탐색하여 네트워크 통해 서버 IP에게 전송.
서버의 TCP는 단편화 된 패킷 재조립.
서버의 HTTP는 클라이언트의 request 수신 및 처리.
서버의 response 송신.

가상 호스트

한 대의 서버가 여러 도메인을 자신에게 향하게 해서 서버가 여러대 있는 것처럼 보이게 하는 것
클라이언트가 도메인만 입력하면 어느 호스트에 대한 요청인지 알 수 없으므로. url에 호스트를 바드시 포함시킬 것.
ex) ko.wikipedia.org 에서 ko = host

통신 중계 서버

클라이언트와 서버 사이에서 통신을 중계한다.

프록시 서버 : 캐시 사용 및 엑세스 제한시 사용.
게이트 웨이 : 프록시와 비슷. 암호화 등에 사용.
터널 : SSL 이용 통신 보안에 사용. 클라이언트는 존재를 모름.

캐시는 캐시서버나 클라이언트 내부에 저장.
리소스를 일일이 서버에 요청하지 않고 가까운 서버나 자신에게 있는 캐시 리소스 가져다 사용

HTTP

응용 계층의 프로토콜
웹에서 클라이언트와 서버간에 통신을 담당.
Stateless 한 프로토콜 (이전 통신 기록 기억하지 못한다) -> 로그인 풀리는 문제 발생. 쿠키로 해결
서버가 첫 Response시 쿠키 붙여 송신. 다음 클라이언트의 Request 부터 해당 쿠키 붙여 송신하면 서버는 전에 왔던 클라이언트 임을 인식.
클라이언트가 request 보내면 서버가 response 보내며 통신.
TCP 연결 후 request, response 주고 받은 뒤 연결 종료.
최근에는 TCP 연결 오버헤드를 줄이기 위해 Persistent TCP나 Pipelining 사용.
- Persistent TCP : TCP 연결 유지한 상태로 Request, Response 여러번 주고 받자.
- Pipelining : Request 한번에 우루루 보내고. Response도 한번에 우루루 받자.
효율 높이기 위한 엔티티(메시지에 담긴 데이터) 인코딩.
- 콘텐츠 코딩 : 정보 유지한 채로 압축.
- 청크 전송 코딩 : 작게 쪼개서 송신. 순서대로 복원.
콘텐츠 네고시에이션 : 미국/한국판 사이트. PC용/스마트폰 용 사이트 처럼 더욱 적합한 리소스를 선택해서 제공하는 것.

Request

클라이언트가 서버에게 보내는 요청 HTTP 메시지.
헤더는 메소드. URI. 프로토콜 버전으로 구성
- 메소드 : 서버에게 어떤 요청을 하는지
  GET : 너가 갖고 있는 이 리소스 보내줘.
  POST : 너에게 데이터를 보낼게.
  GET방식을 통해서도 쿼리스트링을 통해 서버에 데이터 전송 가능하나 보안적 문제.
- URI : 어떤 리소스를 원하는지
- 프로토콜 버전 : 사용하는 HTTP 버전이 무엇인지.

Response

서버가 클라이언트에게 보내는 응답 HTTP 메시지.
헤더는 프로토콜 버전. 상태 코드로 구성.
- 프로토콜 버전 : 사용하는 HTTP 버전 무엇인지.
- 상태 코드 : Request의 처리 결과
  - 1xx : 처리중
  - 2xx : 성공
  - 3xx : Request 완료 위해 추가 동작 필요
  - 4xx : 클라이언트 에러. Request 메시지 오류.
  - 5xx : 서버 에러. Request 이해는 하였으나 처리 실패.

HTTPS

HTTP 보안문제 해결을 위한 솔루션

HTTP의 보안문제

도청 가능 : 암호화 안하고 TCP/IP 패킷은 누구나 캡처 가능.
위장 가능 : 서버인척 위장하고 데이터 요구할 수도 있음.
변조 가능 : 수신시 데이터가 송신시 데이터와 같은지 증명할 수 없음.

HTTPS : HTTP와 TCP 사이에 SSL 프로토콜 추가한 것. 보안기능 추가됨.

암호화 : 터널 등을 통해 클라이언트와 서버 사이의 통신 자체를 암호화 시킴.
증명서 : 서버에 대한 제 3기관의 증명서 발행. 클라이언트는 서버의 증명서를 보고 통신함. 클라이언트의 증명서는 본인확인에 사용.
완전성 : 송신시 데이터를 압축한 digest 등을 통해 수신시 완전성을 증명할 수 있게함.

HTTPS는 속도 상의 문제로 공통키 교환에 공개키 방식. 그 후에는 대칭키로 암호화 진행.
대칭키 : 암호화와 복호화에 같은 키 사용
공개키 : 암호화에는 public key를. 복호화에는 private key를 사용.
1. 서버가 제 3기관에게 자신 공개키를 증빙받음.
2. 클라이언트는 서버의 공개키로 암호화해서 서버에 데이터 전송.
3. 서버만이 비밀키 갖으므로 해당 데이터 복호화 가능.

kiwonkim

이전 포스트