230619 10주 1일차 TIL. Queue, HTTP

Queue

큐는 대기열이라는 의미를 갖고 있음.

스택과는 다르게 선입선출 자료구조이다.

가장 먼저 추가된 자료가 먼저 나옴. FIFO

 

스택은 입출력이 한 방향이었기 떄문에 top 변수를 사용해야 했음.

but queue는 입출력이 다른 곳에서 이뤄지기 때문에 데이터의 첫부분과 끝부분을 가리키는 변수가 필요.

 

 

앞부분을 가리키는 front와 끝부분을 가리키는 rear를 사용.

deQueue할 땐 front 하나 증가.

enQueue할 땐 rear 하나 증가

isEmpty() ⇒ front == rear일 경우

 

queue의 문제점!

앞부분의 공간이 비었지만 front와 rear가 계속 뒤로 이동하며 queue가 꽉찼다고 인식하게 됨!

⇒ 잘못된 포화 상태 인식이라고 함. 그래서 원형 큐를 사용하는 방안을 도입.

 

나머지 연산자를 사용하여 인덱스를 할당하면

데이터의 이동 없이 빈 공간에 데이터를 할당할 수 있다

 

원형 큐의 문제점

front == rear 일 경우 empty로 인식하게 되는데

원형 큐가 꽉찰 경우 rear가 front와 값이 같아지게 되며 꽉찬 큐를 empty로 인식하게 되는 문제점이 있다.

그래서 실제 사이즈보다 배열의 크기를 하나 더 크게 만들어야 한다.

Spring Boot & HTTP

스프링 부트는 http 서버를 만들기 위해 사용한다.

url의 scheme 부분에 http 또는 https를 붙이게 됨.

 

 

http란 

html등의 자원을 주고받는 방식

인터넷 상에 데이터가 오가는 방식보다는 데이터가 실제로 어떻게 구성되어 있는지

TCP : Transmission Control Protocol

IP : Internet Protocol

얘네들 각각이 무언가를 표현하기 위한 규약이다.

tcp, ip, http가 각각 표현하는 규약이 다르다.

OSI

물리계층

- 실제로 신호가 오가는 부분. 케이블, 리피터. 물리적 신호가 오가는 부분

 

데이터 링크 계층

- 사설망 내부에서 어떤 컴퓨터로 연결할 지 등을 정하는 부분. 물리적 신호가 오가는 부분

 

그래서 tcp/ip에선 이 두 부분을 네트워크 접근 계층으로 묶음

 

네트워크 계층. 인터넷 계층

- 인터넷 : 수많은 컴퓨터들이 연결되어 있는 네트워크

- 컴퓨터를 식별하기 위한 계층.

- 어떤 컴퓨터가 어디있는지(위치)를 나타내기 위한 계층

 

전송 계층

- 데이터가 오가는 과정에서 문제 없이 데이터가 오고 가게끔.

- 데이터가 온전하게 도착했는지, 데이터가 전송이 끝났는지 등등..

 

전송 계층까지 도착을 하면 데이터가 정상적으로 도착했다고 할 수 있음

그 다음 규약부터는 그 전달된 데이터가 어떤 모양인지? 어떻게 생겨먹은 데이터인지에 대한 규약이

응용 계층이다!

 

1~4계층까지는 스프링부트에서 해줌

그 다음 부터는 우리가 어떤 데이터를 담고 있는지 확인하고 어떤 형태로 전달할 것인지를 설정해줘야함.

 

그래서 http란 데이터를 주고 받았을 때 그 데이터가 어떤 모양인지를 말한다..

 

스프링부트 내부에서 작업할 때는 데이터가 정상적으로 도착했다는 것을 가정하고

그 다음만 걱정하면 된다! 데이터가 어떤 형태인지 등을..

 

 

HTTP란

클라이언트와 서버가 이야기를 나눌 때 주고받는 문서의 양식 같은 것,

html 문서와 같은 자원을 주고받을 수 있도록 하는 규약

client-server protocol이라고도 한다.

직관적으로 해석하면 말 그대로 hypertext를 전송하기 위한 규약이다..

Request Line

- POST /example HTTP/1.1

- HTTP method , url 경로, HTTP 버전

- 요청에 대한 전반적인 정보를 모두 담고 있음

 

http method

get → 가져오다, post → 붙이다, delete → 삭제하다

http method란 그 뒤에 오는 url의 데이터에 대한 동작을 말함.

 

Request Headers

- 요청에 대한 부수적인 정보가 표현됨.

- 내가 지금 보낸 데이터를 어떻게 해석해야 하는지, 어떤 형태의 응답을 기대하는지 (Accept 부분)

- ex) html 형태이고, json 형태로 해석해야 한다 등emd..

Request Body

- 실제 데이터가 추가된 부분

- 예시에서 http method가 post였으므로 데이터를 붙이는 요청인데 이때 실제로 붙일 데이터가 여기에 담겨있음

- 요청을 통해 전달하고 싶은 실제 데이터 부분

 

 

post는 일반적인 의미의 create를 말하고

put은 일반적인 의미의 update를 의미한다고 해석하면 됨.

 

멱등성 ? 

서버에 요청을 몇번을 보내든지 미치는 영향이 똑같다면 put 사용. 아니라면 post 사용

 

 

HTTP Response

 

Status Line 

- HTTP/1.1 200 OK

- 요청을 어떻게 처리해야 하는지.

- 요청의 처리결과를 표현하는 것

- 404, 200 에러 등이 여기에 들어감~

 

Response Header

- 보통 서버에서 직접 만들어서 줌

- response body에 있는 데이터를 어떻게 해석해야하는지를 정의

- 응답에 대한 부수적인 정보

 

Response Body

- 요청을 통해 전달하고 싶은 실제 데이터

 

http status codes

- 100 ~199 : 인간이 보려고 만든게 아님

 

- 200 ~ 299 : 요청이 성공적으로 처리됨. 어찌됐건 요청이 성공했을 때 반환되는 코드
  201 : http 요청 실행을 받은 후  자원 생성 성공 상태
  202 : 요청은 받아들여졌으나 아직 동작을 수행하지 않은 상태.
  204 : 요청을 성공했지만 제공할 내용이 없음.

 

- 300 ~ 399 : 얘도 우리가 직접적으로 마주칠일은 없음. 얘는 일반적으로 redirect 용도로 많이 사용. 요청 처리를 위해 클라이언트의 추가적인 행동이 필요

 

- 400 ~ 499 : 클라이언트가 처리가 불가능한 요청을 한 경우..
  400 : 클라이언트가 잘못된 요청을 보냈을 때 

  401   로그인한 사용자가 로그인하지 않고 정보를 요청했을 때 ?? 다시 검색 ㄱ
  403 : 요청을 했지만 처리할 수 없는 요청일 경우
  404 : 찾을 수 없는 자원을 요청했을 때

 

- 500 ~ 599 : 서버에 문제가 생겨서 처리가 불가능해진 경우

  500 : internal server error. 서버 내부에 문제가 생김. 예외처리를 똑바로 안했거나 db가 죽어서 정상적인 응답을 못했을 경우. 서버가 요청을 제대로 처리하지 못했을 경우 발생