네트워크 이해하기 (책 : 그림으로 배우는 HTTP NETWORK Basic) (1)

회사에 다정한 선배님들, 첫! 담당 사수님이 생겼다.

​

내 사수께서 클라(프론트)와 네트워크에 대해

알려주고 싶다며 책을 대여해주셨다. (눈물줄줄)

그래서어~ 열심히 공부 및 암기를 해보았다.

간략히 설명과 용어를 공유하고자 한다.

​

​

​

[ 클라이언트 ] 서버를 의뢰하는 웹 브라우저

- 클라이언트 가동 방식 : 주소(url)로 웹 서버 리소스 파일의 정보를 얻어 작동

​

[ URI(리소스 식별자) ] : HTTP, FTP, MAILTO, TELNET..

- URL : URI의 서브셋, 리소스의 장소를 나타냄

​

[ 메소드 ] : URI로 지정한 리소스에 리퀘스트를 보냄

- GET, PATCH, PUT, POST, DELETE

​

​

[ 프로토콜 중 TCP/IP ] : 인터넷 네트워크를 움직이는 프로토콜, 계층 순서적용 통신

* 프로토콜은 기기와 네트워크 통신규약

IP	네크워크 계층, 개개인의 패킷을상대에게 전달, 변경가능
TCP	송신패킷(SYN)/수신패킷(SYN/ACK), 신뢰성 있는 단위 패킷을 분해 후 관리

- OSI 7레이어 구성 계층

: 응용 계층(ftp, dns,http) / 전송계층(tcp, udp) /네트워크 계층(전송데이터 최소단위 = 패킷 )/

물리계층 = 링크계층(하드웨어 측면 = 인터페이스카드 NIC, 커넥트 등 물리적 부분)..

ㄴ HTTP : 응용계층, 클라(리퀘스트)~서버(응답) 간 소통으로 흐름 결정, 클라이언트가 리퀘스트 송신마다 URI를 리퀘URI형식에 포함, rfc2616는 HTTP/1.1 사양 의미

ㄴㄴ 인코딩 : http 데이터의 전송 효율이 높아짐

= 메세지 바디(http 기본단위) + 엔티티 바디(페이로드로 전송되는 정보)

* 콘텐츠 코딩 = 엔티티에 적용되는 코딩, 수신한 클라이언트측이 디코딩 함

 

ㄴ DNS : 응용계층시스템에서 도메인/IP 주소 및 이름 확인

​

- 지속연결 : 한쪽이 명시적으로 종료를 하지 않는 경우 계속 유지 => 오버헤드를 줄이고 웹페이지 빠른표기O

​

- IP 통신 : MAC주소에 의존하여 목적지를 ARP프로토콜로 찾아감

​

- 단점 : 소통중에 상태관리X(스테이트리스)=> 쿠키를 통해 유지한계성을 보완

* 쿠키는 클라이언트에 보존되고 이는 서버가 기록여부를 확인하는 데이터로 사용됨

ㄴ 쿠키는 HTTP/1.1 사양 포함은 아니나 유지 식별과 상태관리를 진행

HTTP 메소드
GET	리퀘가 URI로 식별된 리소스를 가져옴 (텍 => 텍)(GGI(프로그램)>실행>출력)
POST	엔티티 전송
PUT	파일 전송 리퀘 중 포함 엔티티를 리퀘URI로 지정한 곳에 보관 요구
HEAD	URI 유효성 및 리소스 갱신시간 확인
DELETE	파일 삭제 요구
OPTIONS	리퀘 URI로 지정한 리소스가 제공하는 메소드 조사
TRACE	웹 접속 후 통신을 되돌리는 루프백 유발 수치 = 0(끝), 마지막수신지(200 OK)
CONNECT	포트 HTTP 버전

[ HTTP/1.1(rfc2616)) 헤더 필드 일람]

헤더 필드명	동작
Cache-Control	캐싱 동작 지정
Connection	hop-by-hop 헤더, 커낵션 관리
Date	메세지 생성 날짜
Pragma	메세지 제어
Trailer	메세지 끝 헤더의 표지
Transfer-Encoding	메세ㅔ지 바디 전송 코딩 형식 지정
Upgrade	타프로토콜에 의한 업그레이드
Via	프록시 서버에 관한 정보
Warning	에러 통지
Accept	User-Agent가 처리 가능한 미디어 타입
Authorization	웹 인증을 위한 정보
Expect	서버에 대한 특정 동작의 기대
Range	엔티티 바이트 범위 요구
TE	전송 인코딩의 우선 순위
User-Agent	HTTP 클라이언트 정보
Location	클라를 지정한 URI에 리다이렉트
Server	프록시 서버에 대한 캐시 관리 정보
Allow	리소스가 제공하는 HTTP 메소드
Expires	엔티티 바디 유효기한 날짜

[ 헤더필드 ]

- Via : 헤더필드 중 하나, 클라와 서버간 리퀘/리폰 경로 확인용, 프록시나 게이트웨이가 자신 서버 정보를 via 헤더 필드에 추가한 뒤 메세지 전송, traceroute(경로추적)과 유사

​

- Accept : 헤더필드 중 하나, 미디어타입을 위함

ㄴ png를 브라우저가 처리하지 못하면 accept에 지정하지 않고 처리가능한 image/gif 혹은 image/jpeg 지정

​

- Host : 리퀘한 리소스의 인터넷 호스트 및 포트번호 전달, http/1.1의 유일 필수 헤더 필드, 도메인 구분 용도

​

- 리스폰스 헤더 : 서버에서 클라로 송신되는 리스폰스 메세지에 적용된 헤더, 리폰/서버/클라 부가 정보 요구 표기

​

- DNT : 개인정보 수집 거부 의사인 HTTP의 리퀘스트 헤더

​

- VARY : 오리진 서버가 프록시 서버에 로컬 캐시 사용법을 컨트롤

​

- 서버 : 서버에 설치된 HTTP 서버 소프트웨어 전달

​

​

[ 헤더 요청 소스 ]

- if-match : 리소스를 서버에 특정하기 위해 엔티티 태그값(Etag) 전달, 비일치시 412 Precondition failed 리스폰스 반환, *지정시 Etag값 구애없음

​

- TE : 리스폰스로 받을 수 있는 전송코딩 형식과 상대적 우선순위를 전달하는 헤더필드

ㄴ TE : traliers

​

[ 품질 계수의 지정 ] : 0~1 중 1쪽이 높음

- 품질1 예시 기입 : q=1.0

​

[ 멀티파트 ] : 다목적 메일 확장사양 mime 중 여러 다른 종류 데이터를 수용하는 방법, 헤더필드 포함

- 엔티티 구분 : boundary , 앞뒤로 -- 붙이기

​

​

[ 상태코드 ] : 클라가 서버로 리퀘를 보낼때 결과가 어떻게 되엇는지 알려주는 역할

- 구성 : 세자리 숫자 + 설명 (ex - 200 ok)

- 클래스(첫자리) , 나머지자리 = 분류x

(1) 1xx information : 리퀘 정상처리중

(2) 2xx success : 리퀘 정상처리 완료

* 204 no content = 리퀘성공but 수신화면변동x

* 206 partial content = 부분적 get 리퀘를 받음

​

(3) 3xx redirection : 리퀘완료를 위한 추가동작 필수

* 301 move permantly = 리퀘에 새url가 있어 이후에 그 리소스를 참조하는 url을 사용, 디렉토리 저장시 슬래시 잊은 경우 발생

* 302 found = 일시적인 이동이 된 새url의 할당으로 그 url참조 필요

* 303 see other = 리퀘리소스가 다른 url에 있어 get 메소드 사용이 필요

* 304 not modified = 조건부 리퀘시 리소스 허락 but 조건충족없음, 유일하게 3xx 중 리다이렉트와 무관

* 307 temporary redirect = not found, 브라우저 사양따른 post에서 get 치환이 아닌 브라우저마다 동작 다양

​

(4) 4xx client error : 서버가 리퀘 이해 불가

* 401 unauthorized = 리퀘에 http인증필요

* 403 forbidden = 리퀘된 리소스의 액세스 거부(퍼미션 미부여/엑세스 권한 문제)

* 404 not found = 리퀘한 리소스가 서버에 없음

​

(5) 5xx server error : 서버가 리퀘 처리 실패

* 500 internal server error = 리퀘처리 중 에러

* 503 service unavailable = 서비스 과부하

* 클래스의 정의를 지키는게 관건

​

​

[ 통신 중계 프로그램 ]

- 프록시 : 양쪽 중계

ㄴ 클라가 순정url 리소스로 리퀘줌 > 타서버 전송 > 리스폰스의 프록시서버 경유 > 클라

​

- 게이트웨이 : 타서버 중계, 프록시와 동작 유사, 클라와 사이를 암호화 하여 안전접속 시킴

​

- 터널 : 떨어져있는 클/서의 중계

​

​

[ 리소스의 캐시 ] : 언어가 다를 경우 브라우저의 반환 리소스가 다름(리소스 = 언어 )