Http-인터넷 네트워크

인터넷 통신 

 

크라이언트 - - - 서버

 

클라이언트 인터넷 서버

인터넷은 다양한 노드로 복잡하다

> ip

노드의 규칙

패킷단위 전송

 

 

패킷

출발 도착 ip 

 

 

환경에 따라서 경로가 달라질 수 있다

 

 

 

비연결성 - 패킷받을 대상이 없음

> 일단 보내고봄

비신뢰성 - 중가에 사라지거나 순서구분(용량) 

>>>>> tcp나옴

 

 

 

어플리케이션  - 앱 - 소켓라이브러리

전송계층 tcp

인테넷  ip

네트워크 인터페이스- 랜 드라이버 장비 

 

 

http> tcp> ip > 이더넷 프레임

 

 

tcp (전송제어 프로토콜)

-포트

-전송제어

-순서

-검증정보

 

>연결지향 - 연결 후 메시지를 보냄

> 데이터 전달 보증

>순서 보장

신뢰가능!

 

3웨이 핸드쉐이크 - 개념적 연결

신

신액

액(데이터)

 

순서보장 - 잘못된 순서부터 다시 받음 (최적화는 내부적으로 진행)

 

udp - 포트만 추가됨 ip랑 개념이 같다 

udp > 가 뜨고있다! 최적화되어 튜닝 가능

 

 

프로그램 구분 - 같은 ip에서 어플리케이션이 많으면? 

 

>

포트 - 한번에 여러가지 연결할 경우

1023 까지는 잘 알려진

443 - https

 

 

dns > ip는 기억하기 어렵고 ip가 바뀔때

전화번호부!

도메인 명을 ip로 변환

 

 

 

 

uri - 소스를 식별하는 방법

로케이터 이름 둘다 식별

= url(로케이터) + urn (이름) - 거의 안씀

 

 u 리소스 식별 방식 

r 자원

i 다른 항목과 구분하는데 필요한 정보

 

위치는 변할수 있지만 이름은 변하지 않는다

 

 

아직 이름만으로 리소스를 찾는 방법이 보편화 되어있지 않음

 

url

 

 스키마 - 프로토콜(서버 접근 방법) http 80 https 443     (포트 생략 가능)           ftp

사용자 정보 ( 보안상 거의 안씀)

주소

경로 (소스 경로) > 계층적 되어있음

퀴리 키벨류로 데이터가 들어가 있음

q 값

hl 언어정보

?로시작 &로 추가

쿼리 스트링으로 불림

 

프래그먼트 - 서버에 전송없이 html 내부에서만 쓰임

 

 

 

웹브라우저 요청 흐름

 

1. dns조회 생략된  포트번호 생성

http 요청 매시지를 보냄

 

 

 

 

 

 

그럼 서버가 노랑이 버리고 응답 메시지 만듬 후 전송 

 

 

 

http란?

hyper text transper protocol 

지금은 이미지 영상 파일 json 등 모든것을 전송 가능

 

http/1.1 > 가장 많이 사용 1997년

99년 14년에 개정이 됨

 

2,3 는 성능 개선

 

12는 tcp기반

3는 udp기반

 

h2 h3 이런식으로 표기하기도함

 

 

 

클라이언트 서버 구조

클라이언트가 요청하고 서버가 응답함

불리가 중요함

- 클라이언트는 사용성 - ui ux 그리기

- 서버는 기능 (언어를 바꾸는 식의)

 

무상태 프로토콜 지향 (스테이스 리스)

서버가 클라이언트 상태를 유지하지 않음>> 무한 서버 증식 가능(쉽개 바꿀수 있다) 클라이언트가 증가해도 서버증설 가능

(중계서버를 거쳐 점원(서버)에 전달)

한계점 - 로그인 유지와 같은 부분이 어렵다 , 데이터를 너무 많이 보낸다

(브라우저의 쿠키와 서버의 세션을 활용)

 

반대는 stateful (클라이언트가 누구인지 기억)

 

 

 

비연결성

연결 응답 종료 > 자원을 아낄수 있다.

서버 자원을 효율적으로 사용할 수 있다. 

지금은 지속 연결 

연결 응답 종료 반복이 아닌, 

요청응답요청응답요청응답종료 이런식으로 지속연결을 사용함

 

h2, h3에서는 이런점을 더 개선 가능

 

 

스테이스 리스를 기억하자 

명절 ktx예약처럼 한번에 대용량 올시 > 스테이스 레스를 기억하자 (정적 페이지를 거치게 사용자를 분산)

 

 

http 메시지

 

스타트라인

해더

공백(CRLF)

바디

 

 

시작라인 

리퀘스트 라인 

메서드 - 

겟 포스트 딜리트 등

 

절대경로 시작한다

 

버전

 

 

 

 

 

응답메시지

http버전 스테이스코드 사람이읽을수있는글

 

 

해더

필드이름: ows(띠어쓰기 여부) 필드벨류

 

 

 

 

바디

데이터가 들어감

 

 

 

단순하고 확장가능

스펙도 읽어볼만 함 아마도 

메시지 단순

단단하지만 확장 가능한 기술

 

 

 

 

 

api 를만들자

리소스를 기준으로!!!!!!!!!

회원을 기준으로

목록조회,조회,등록,수정

 

 

uri는 리소스만 식별

행위는 (메소드) 동사 는 http메소드로 구분   (리프렌테이션)

get 조회(캐쉬가 쉽다)

데이터를 쿼리에 담아서 (바디를 지원 안하는 서버가 많음)

post 데이터를 담아서 줌(캐쉬 처리가 어렵다)

데이터를 처리함 등록, 프로세스 처리

새리소스 등록처리, 요청데이터 처리, 다른 매서드로 처리 애매한 모두

만능임 내사랑

put 리소스를 주는데 없으면 생성

patch  부분 변경

delete 삭제

head 메시지를 제외한 get