프론트엔드 개발자로서 그동안 못했던, 네트워크 지식에 대해 정리해보려고한다.
1장
HTTP
웹에서 쓰이는 약속 이라고 생각하자.
HTTP 1.0, HTTP1.1은 1996년, 1997년에 나왔지만, 아직도 많은 곳에서 사용되고있다.
TCP/IP
HTTP의 상위 범주로 인터넷과 관련된 프로토콜을 모은 것.
- 이 프로토콜에는 케이블의 규격, IP주소 지정방법, 웹을 표시하기위한 순서 등등이 있음
계층으로 관리됨
- 계층화되어 관리되는 이유는 각 계층별로 자유롭게 설계가 가능하기 때문에.
- 예를들면, 어플리케이션 층에서는 자기 자신이 담당하는 부분만 고려하면되고, 다른 계층의 역할은 고려할필요가없음
- 계층의 4가지
- 어플리케이션 : 유저에게 제공되는 통신의 움직임 결정, FTP,DNS,HTTP 여기에 포함
- 트랜스포트 :데이터 흐름 담당 , TCP와 UDP 두가지 프로토콜 존재
- 네트워크 : 패킷의 이동을 다룸
- 링크 : 하드웨어적 측면 담당
- 이계층을 클라이언트에서 서버로 전송을 주고 받을때 캡슐화를 거친다.
- 캡슐화 : 보내는쪽에서는 계층을 하나씩 통과할때마다 헤더로 감싼다. 받는쪽에서는 계층을 하나씩 통과할때마다 삭제한다.
IP
- 개개의 패킷을 상대방에게 전달하는 역할, 가장 중요한 요소는 MAC주소(네트워크 카드에 할당된 고유주소, 변경불가)
TCP
- 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 역할
- 3-way Hand Shaking : 클라-서버가 SYN/ACK메시지를 주고 받으면서 연결 잘 되었는지 확인하는 과정 -> 신뢰성을 높인다.
DNS
- IP주소로부터 도메인명을 조사하는 서비스 혹은 반대로 도메인명에서 IP주소를 조사하는 서비스 제공
1장 정리
"google.com 쳤을때 어떤식으로 동작하시는지 아시나요?"
클라는 먼저 DNS에게 google.com의 IP주소를 알려주세요 라고한다.
-> DNS서버는 IP주소를 클라이언트에게 알려준다.
-> 클라쪽에서 HTTP는 HTTP메시지를 작성 ( 나 google.com에 필요한 리소스를 주세요 ) 및 TCP는 통신하기 쉽도록 HTTP메시지를 패킷으로 분해
-> IP는 여러 서버를 돌아다니며, 상대가 어디에 있는지 찾아가게함
-> TCP는 상대방으로부터 패킷을 수신하여 도착한 패킷을 조립 및 HTTP는 웹 서버에 대한 리퀘스트 내용(홈페이지의 소스를 주세요)을 처리
2장
HTTP 리퀘스트 메시지
GET /index.html HTTP /1.1
Host: www.naver.com
GET : 메소드
index.html : 요구 대상인 리소스 = 리퀘스트 URI
HTTP 1.1 : 클라이언트 기능을 식별하기 위한 HTTP 버전 번호
HTTP 리스펀스 메시지
HTTP /1.1 200OK
Dat: Tue,10 Jul 2012 000000:gmt
Content-length: 2222
Content-Type: text/html
<html>
....
HTTP 1.1 : 서버의 HTTP 버전
200 OK : 상태 코드와 설명
HTTP는 Stateless 프로토콜
- 상태를 계속 유지하지 않는다. 이전에 보냈던 리퀘스트, 이미 되돌려준 리스폰스에 대해서 전혀 기억하지 않는다.
HTTP의 지속연결
- 초창기에는 전송한번할때마다의 양이 작았기 때문에 계속 맺고,끊고를 반복하면서 데이터를 전송했어야했다.
- 이 불편함을 해결하기 위해 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 계속 유지한다.
- 연결,종료 과정의 오버헤드를 확줄여서 웹페이지를 빨리 로드할 수 있게 되었음
- 파이프라인화 : 한번보내고 한번받던것을 그냥 여러번 보내버림.
쿠키
- Stateless이기 때문에, 예를들면 로그인한 뒤 로그인한 유저에 대한 정보를 가지고 있으려면 stateless로는 해결이 불가
- 쿠키라는 시스템을 도입해 요청시에 쿠키정보를 추가해 클라이언트의 상태를 파악
- 처음 요청 보낼때, 서버에서 응답을 줄때 Set-Cookie라는 헤더 필드에 쿠키를 붙여서 보내줌
- 이후에 요청시 쿠키정보를 자동으로 리퀘스트 메시지에 붙여서 보내게 되면, 서버에서도 그걸 알고 응답해준다
3장, 4장
HTTP메시지는 헤더, 개행 문자, 바디 3개로 구성
HTTP로 데이터 전송시에는 전송할 때에 인코딩을 해서 전송 효율을 높인다.
상태코드
2xx 성공
200 OK : 정상 응답
204 No Content : 요청이랑 응답은 잘 주고받은거고, 딱히 어떤 응답을 받아서 처리할게 없을때
206 Partial Content: 일부 리퀘스트에 대한 응답(Content-range로 지정된 범위의 엔티티가 포함)
3xx 리다이렉트 - 응답의 결과에 Loaction이 있으면 거기로 자동 이동
301 Moved Permanently : 페이지를 영구적으로 이동시켜버림 , 아예 도메인을 변경할때 사용
302 Found : 페이지를 일시적으로 이동시킴, 페이지 점검중, 품절되었을때 이동시킬 페이지 등
303 See Other: 302랑 기능 같음, 리다이렉트시에 GET으로만
307 Temporary Redirect: 302랑 기능 같음, 307은 리다이렉트시 메소드 유지
308 Permanent Redirect: 301과 똑같은데, 301은 Post요청을 하면 리다이렉트시에 GET요청을 하는데 반해 308은 그대로 POST요청을 함 (메시지본문유지)
4xx 클라이언트 에러
5xx 서버 에러
5장
가상호스트
물리적으로 서버가 1대지만, 가상으로 여러대가 있는거처럼 할 수 있다.
문제점 : 같은 서버 상에 같은 IP 주소의 웹 서버에서 비슷한 url이 실행되고 있을 때 DNS로 이름을 해결하면 똑같은 수신인이 되어버림
리퀘스트시에 호스트명과 도메인 명을 완전히 포함하여 URI를 지정하거나, 반드시 Host헤더 필드에서 지정해야함.
프록시
클라이언트로 받은 리퀘스트를 다른 서버에 전송하는것 , 여러개의 프록시 서버를 거쳐서 오리진서버로 가게된다. 중간에 Via헤더 필드에 경유한 호스트 정보를 추가해야함.
- 캐싱 프록시 : 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시 , 오리진까지 안가고 해당 프록시에서 응답을 돌려줌
게이트웨이
동작은 프록시와 유사함 / 클라 - 게이트웨이 - OO 여기에 들어가는 서버가 HTTP 이외의 서버인 경우
예시) 데이터베이스에 접속해 SQL쿼리를 사용해 데이터를 얻는 곳에 사용, 쇼핑 사이트에서 신용카드 결제 시스템과 연계할때 사용
캐시
프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 복사본
- 같은 데이터를 몇번이고 오리진 서버에 전송할 필요가 없다. -> 클라이언트는 정보를 가까운 네트워크에서 가져올 수 있어 속도향상
유효기간이 존재한다. 유효성검사가 있다. 낡은 것인지 새것인지 판단하는 과정이 있다.
'학습정리 > 자습' 카테고리의 다른 글
| 이펙티브 타입스크립트 정리 - 4장 (0) | 2023.06.09 |
|---|---|
| 이펙티브 타입스크립트 정리 - 3장 (0) | 2023.06.02 |
| 이펙티브 타입스크립트 정리 - 2장-02 (1) | 2023.05.19 |
| 이펙티브 타입스크립트 정리 - 2장-01 (2) | 2023.05.12 |
| 이펙티브 타입스크립트 정리 - 1장 (0) | 2023.05.11 |
