[Server Communication] HTTP, HTTPS, get/post method (app.get, app.post)

 

• 프론트가 물리적으로 떨어져있는 내 웹브라우저까지 와야하는데 
• 백엔드에 요청하고 받아야 하는데 물리적으로 멀리 떨어져잇는 서버에 요청해야하는데 이 통신이 어떻게 이루어지는가 

 

통신 

서버간의 통신이 어떻게 이루어지는가 

 

---

오프라인 커피 구매

→ 서로 같은 언어를 쓰기 때문에 (양자가 서로 이해할 수 있는 공통의 목소리, 성대를 통해 ) → 소통 

주체: 사람, 사람

 

온라인에서 커피 구매 (웹서비스에서는 웹브라우저와 server 간의 소통, 인터넷을 통해_인터넷 기반으로 문자text를 주고받으면 소통 ) 

→ 주체 : 클라이언트(매개체 - 웹브라우저, 모바일 앱), 서버 

---

서버란

서버는 단독으로 움직이지 않으며 불특정 다수의 컴퓨터에 일방적으로 서비스를 제공하는 것도 아니다.

서버는 클라이언트로부터 요청(Request)를 받아야 비로소 처리를 시작하여 서비스를 제공

 

1. 웹 브라우저가 웹 서버에게 'www.naver.com' 사이트 데이터를 달라고 요청

2. 웹 서버는 해당 사이트의 파일을 찾음

3. 웹 서버는 찾은 파일을 웹 브라우저에게 반환

4. 웹 브라우저는 파일을 받아 네이버 메인을 화면에 표시

 

 

서버 

클라이언트에게

네트워크 통해

정보/서비스 제공하는 컴퓨터 시스템 (= 컴퓨터 프로그램/ 장치)

 

서비스를 제공하는 소프트웨어가 실행되는 컴퓨터

클라이언트에게 요청 받아, 응답 내려줌 

 

클라이언트

서비스를 사용하는 컴퓨터 (웹에 접근하는 소프트웨어)

서버에 데이터 요청하고, 응답 받음

서비스

컴퓨터가 인터넷이라는 하나의 거대한 네트워크 구성 (인터넷 통해 다양, 방대한 데이터 공유) 

네트워킹; 2대 이상의 컴퓨터를 케이블로 연결하여 네트워크 구성하는 것

 

---

언어 = set of rules(규칙)

 

같은 언어로 소통한다는건 그 규칙을 이해한다는 뜻

 

서버에서의 언어,

정해진 규칙=  프로토콜

 

서버는

정해진 규칙, 프로토콜로 소통한다! 

 

(Http, ftp 등등 있는데 우리는 http만 배우면 된다) 

---

HTTP

Hyper text : 문서, 문서 링크로 연결되어있다 뜻
Transfer: 보낸다, 전달
Protocol : 정해진 규칙, 
= 서버끼리 전달하는 규칙

 

클라이언트도 http규칙에 맞게 서버에 보냄  by 인터넷

서버도 http 규칙에 맞게 정해진 문자열text을 보냄 by 인터넷

 

Cf. Tim Berners lee (world wide web의 아버지) 

Http, html .url (주소) inverter 다 발명함 → world wide web 생김 (www)

 

• Html을 서버끼리 주고 받을 수 있게 만든 protocol = http 
• 주소 처럼 사람이 직관적으로 이해할 수 잇는 구조가 필요하다 = url 

 

HTTPS 

Http 규격에 맞춘 문자열로 전달되는데,

단순 문자열이기 때문에 중간에 가로챌 수 있다. 

보안 취약점 있음 

 

문자열을 보내는 것이다 보니, 누가 중간에 가로채면 내 아이디 비번을 누가 알게 되는 것

 

Ex. 말로 이야기 하는데 중간에 말을 누가 들으면 전파되는거처럼

 

그래서 http를 암호화 시킨 것

서로 소통하는 두 주체만 알 수 있도록 

암호화돼서 제3자는 알 수 없음. 

 

Http + ssl = https 

 

보안 중요한건 거의 이거 사용

 

---

 

http를 알아야 http를 베이스로 하는 걸 만들 수 있다 

 

HTTP 두 가지 특징 

1. request/ response

소통 = 요청 + 응답 

• 요청하는 주체: client 
• 응답하는 주체: server / host 

• 요청이 시작점, 응답이 그 다음
• 요청 받으면 무조건 해줘야 함. 안하면 에러

2. Stateless : http는 상태가 없다 

Http 개별 통신은 모두 독립(자기만 안다)

과거 http 통신 결과/상태를 보존 안 함 (지금 이 순간의 소통만 안다. 과거에 소통이 있었는지 없었는지 모른다) 

---

Ex. 내가 로그인을 하는데,

http는 내가 이전에 로그인 통신이 있었는지를 모른다. 

 

그 전의 요청 사항을 모름. 

두 번째 대화를 하더라도. 

---

오프라인 카페에서는,

매번 시럽 추가 해달라 하면 기억하지만,

 

http는 모른다. 

해당 대화만 안다. 그외 정보는 아예 안 갖고 있다.

---

그렇기 떄문에 요청을 할 때마다

처음의 정보를 모든 걸 다 가져간다. 

아이스 아메리카노 얼마에요?

아이스 아메리카노 얼마에요?
시럽 2개 넣어주세오 

아이스아메리카노 얼마에요?
시럽 2개 넣어주세요
얼음 빼주세요 

로그인

로그인
클릭

로그인
클릭
마이페이지

 

이렇게 다 정보를 가져가야 함.

그래야 로그인인 줄 안다.

 

로그인 정보가 없으면 로그인 안 한 줄 앎

 

(비밀번호 아이디를

매번 보내면 안되니, 민감한 정보는 암호화/토큰화 시켜서 보냄: 인가 인증) 

 

모든 정보를 다 담아서 요청한다! 

---

Http 메세지 종류 

1. Request

2. Respone 

---

1. Request 메세지 구조 

1-1. Start line 요청의 첫번째 줄 3개  ex.POST/login HTTP/1.1

       1) Http method로 표현 → 요청이 의도한 액션 (ex. get으로 시작:  달라는거니까, 블로그 썼다: Post 생성)

       2) Request target: 요청이 들어가는 상세주소/ 요청이 전송되는 목표 url

                                        = 상세주소 (테헤란로 427)

                                         Cf. naver.com 은 주소가 아님 (서울시) 

      3) Http version  명시 : keep updating 되니 현재 사용하는 버전 명시 

 

1-2. Headers 요청 자체에 대한 메타 데이터 

• {key:value} 형태

Headers: {

Host: www. 실제도메인 주소 (서울시)                    # host + request target 합치면 정확힌 주소 나옴 (서울시 + 테헤란로 427) 

content-type: application/json                               # jsontpye로 보내고 있다, 너도 jsontype로 처리해야해 

Content-length: 50

}

 

1-3. Body: 요청 실제 내용 

보낸 데이터 없을 수도

- 주세요 / 생성해주세요  

 

실제 주소는 host + request

---

 

2. Response 메세지 구조 

2-1. Status line 

요청에 대한 응답 = 응답에 대한 상태 (요청을 어떻게 처리했는지 알려줘야) 

알려줄게, 안돼, 꺼져 

 

1. Http version : request message와 같음 
2. Status code; 응답상태코드/ 상태를 숫자로 얘기 
3. Status text: 응답상태 간략 설명 텍스트/ 사람도 이해하라고 같은 내용을 텍스트로 알려주는 거 (숫자로 이해하기 어려우니 다시 얘기해주는거)

Ex. HTTP/1.1 404 Not Found 

HTTP/1.1 200 SUCCESS

 

 

 

나머지 두개는 request 메세지 구조와 같음 (start line, status line만 다름)

2-2. Headers 

2-3. Body 

2,3번째 Headers, Body는 request 메세지 구조와 같음 (start line, status line만 다름)

 

---

HTTP Request Methods

굉장히 많은 데 자주 쓰이는 3개만 알면 됨 

 

1-1. GET (가져오는거, 읽어오는거 퉁쳐) 간단하게 할수록 좋음

• 정보를 달라

1-2. POST(변화는 post 퉁쳐 - delete 안쓰기도)개발자 선택사항 최대한 method 적게 쓰는 방향 

• 데이터를 생성 및 수정할 때 주로 사용하는 메서드, 대부분의 경우 요청에 body가 포함되어 보내짐
• Post put 하기도 (회사마다 다름) delete 안 쓰고 변화있는건 다 post로 퉁치기도

1-3. DELETE

• 서버에서 저장된 특정 데이터를 삭제할 때 사용하는 메서드

---

Status Code 

1. Success 정상처리 / status id, text 

• 200: OK 
• 201: Created 잘 생성되었어요 
• 204: No Content 요청을 잘 처리했는데 줄게 없어, 되돌릴 건 없어 

많은데 3개,

근데 이것도 200: OK로 퉁칠 수도

(회사의 개발팀이 결정하기나름, trend는 simple하게 개발 쉽게 하는 거)

  

2. Error 에러 요청하는 주체가 잘못 주체 

• 400: Bad Request 너가 지금 요청을 잘못했다. (데이터 빼먹고 보낸거: id/pw해달라했는데 id/pw가 없는거)
• 401: Unauthorized 권한 - 로그인이 돼어야만 가능한거 (로그인 먼저해야해)
• 403: Forbidden 권한 - 로그인 됐더라도 권한 없을 수도 (무료 유저가 유료 결제 컨텐츠 접근시) “당신은 권한이 없습니다)/ admin만 볼 수 있는거
• 404: Not Found 요청한 url 존재하지 않는다 (서버로 연결은 됨, 이런 주소 데이터 없어) 서버를 못 찾은거랑 다름

 

3. Server Error 서버에서 에러가 나서 처리 못할 때 

• 500: Internal Server Error 

요청 자체를 보고 문맥 이해할 수 있게 http 규칙에 맞게 한 거 
Restful api 
주어진 요청 보고, http 규칙에 맞게 해석하면 됨 

 - 명사 → 주소 
-  동사 → method ‘생성한다. 수정한다'
- 실제 데이터 → body