1. 통신
1) 통신의 역사
- 세계 대전을 통해 유럽에서 발전
→ 통신을 하기 위한 문자 단위는 당연히 영어 문자
- 영어 문자 : 8bit로 표현 가능
실제는 7bit(128가지의 경우의 수)만 있으면 됨
- 8bit(256가지의 경우의 수)
: 모든 대문자, 소문자, 숫자, 특수 문자를 표현할 수 있는 범위
- 8bit 단위로 전송되는 데이터 : 2진수 / 아스키 코드를 통해 변환 가능
- Parity bit
1bit 오류를 검출하기 위한 것
짝수 패리티(Even Parity) : 데이터의 각 비트의 값 중에서 1의 개수가 짝수가 되게 함
홀수 패리티(Odd Parity) : 전체 비트에서 1의 개수가 홀수가 되도록 해야 함
→ 하나씩 선을 타고 가니까 데이터가 유실될 수 있음 그래서 홀수로 나오면 재요청
하지만 두개가 유실되면 알 수가 없기에 이 방법도 완벽할 순 없음
- 통신은 bit 단위로 전송
하지만 인간은 8bit 단위로 끊어 읽어야함
- 인간은 모든 것을 추상화함
인간은 Byte로 사용
스프링은 키로 짤라서 파싱까지 해줘서 점점 더 추상화됨
- 통신으로 전달되는 데이터는 물리적으로는 광케이블로 전송
논리적으로는 Byte Stream을 통해 전송
- 통신으로 전달되는 데이터 메모리에 저장 / CPU로 처리가 가능해진다.
- 메모리 공간의 최소 단위는 8bit이다. 왜?
8bit 단위로 전송되는 영문자는, 한글, 중국어, 고대 고어, 일본어를 표현하지 못함
각 나라마다, microsift같이 자기들 만의 인코딩 방식을 만들어냄→유니코드 등장
유니코드 : 전세계 표준 문자 전산 처리 방식 //정리해야함
타임스탬프 : 전세계 표준 시간 //정리해야함
html5 : 이때부터 전세계 표준 //정리해야함
브라우저 제조사 마다 태그가 다를 수 있기에 표준임
⇒ 모든 문자를 표현하는 문자 인코딩 방식이 필요
UTF-8(완성형과 조합형)
2) TCP/UDP 통신
- TCP 통신 : 신뢰할 수 있는 통신
데이터 요청 후 응답을 받음
- UDP 통신 : 신뢰할 수 없는 통신
응답없이 그냥 던지는 것
2. 소켓통신 기본
1) TCP/IP는 무엇인가?
- TCP Layer에서 세그먼트로 쪼개짐
- ip Layer로 내려가서 세그먼트가 패킷으로 바뀜(목적지 주소가 생기니까 ip Layer)
둘 다 붙어있다고 생각해도 됨
- 데이터가 흘러내려가서 세그먼트로 바뀌고 패킷으로 바뀜
- 최종적으로 하드웨어 램까지 내려와서 가장 가까운 라우터로 갈 때 패킷이 프레임을 타고 데이터가 전송됨
- 첫번째 라우터에 도작해서 프레임에서 패킷이 내려서 새로운 프레임을 타고 이동함
2) Stream
- 우리는 Byte로 전송할꺼니까 스트림 버퍼라고 알면 됨
- 스트림(Stream)이란?
스트림을 가장 쉽게 이해하려면 수도꼭지를 생각하자
수도꼭지를 틀면 물이 나오고 수도꼭지를 잠그면 물이 나오지 않음
A라는 곳에서부터 B라는 곳까지 수도관이 연결 = 스트림이 연결
양 끝단에 문인 소켓이 연결
소켓을 통해서 포트를 통해서 진입
스트림을 얼만큼 받을지 조절하는 것 : 프로토콜
A에서 계속 물을 보낸다면 B에서 수도꼭지를 틀 때마다 물이 나옴
물(전류)의 흐름 : A수도관에서 B수도관으로 이동
- 스트림의 종류
파일 데이터 : 파일은 그 시작과 끝이 있는 데이터의 스트림
용량이 다다르기에 끝이 정해져 있지 않음
파일도 내부적으로는 스트림임
계속 흘러와서 축적이 될 수도 있고 사라질 수도 있음
하드디스크랑 파일이 연결된 스트림
HTTP 응답 데이터 : 브라우저가 요청하고 서버가 응답하는 것도 스트림
키보드 입력 : 사용자가 키보드로 입력하는 문자열은 스트림
키보드랑 메모리랑 연결된 스트림
⇒ 양 끝단에 타켓들이 있어야 스트림을 만들어낼 수 있음
통신에서만 소켓이 있음
3) 버퍼
- 데이터를 8비트씩 읽기 때문에 16비트를 쏘면 스트림을 타고 내려갈때
os가 8비트씩 두번 소비해야함
ex) 500비트를 쏘고계속 소비가 안되고 쌓여있으면 데이터가 유실됨
→ 버퍼에 담아서 버퍼로부터 os가 소비하게 만들어야 함
- 버퍼는 메모리 = RAM
렘에 있는 데이터가 소진이 다 될 때까지 소비하라는 것
ex) 프로세스는 여러 애들한테 데이터를 전송하고 싶을 때가 있음
3명한테 500비트씩 쏘고 싶을 때
1명한테 500비트 주고 씹고 있을 때 소비하는 동안
프로세스가 동기화가 걸려있음
→ 프로세스가 스레드 3개를 만들어서 각각 500비트씩 던져줌
단점 : 컨택트 스위칭 걸리면 너무 느려짐 / 스레드로 왔다갔다하는 것이 느림
- 순차적으로 보내려면 버퍼가 필요함
데이터는 순차적으로 내려주는 것이 제일 빠름
프로세스 입장에서는 스레드 하나로 버퍼에 집어넣고
다음 버퍼, 다음 버퍼에 집어넣고 다른 일 하러가고 버퍼가 알아서 일을 함
- back pressure
뒤에서 압박해주는거?
버퍼는 컨슈머와 프로듀서 //생산자와 소비자
생상자가 버퍼에 데이터를 밀어넣으면 소비자가 소비함
소비자가 생상자보다 늦으면 맞지 않음
생상자가 소비하는 자보다 늦어도 맞지 않음
이거의 균형을 맞추는 것이 pressure → 나중에 소프트웨어 설계를 할 수 있음
어차피 하드웨어는 소비할 수 잇는 양이 정해져 있는 것이 아닌가?
1초에 새우깡을 10개 먹을 수 잇으니 백프레셔가 필요없다고 느껴질 수도 있음
하지만 소비할때 나랑만 통신하지 않을 수도 있음
동시에 두세명과 통신할 경우 10개에서 5개로 줄여들 경우 pressure로 조절하는 것
버퍼가 소비가 안되면 버퍼링이 걸려서 다음애가 데이터를 넣을 수 없음
4) 소켓통신 이해
- 단방향 : 선이 하나밖에 없음
데이터를 쓰면 읽고 처리하고 응답없이 끝나는 것 / os레벨에서 일하는 tcp랑 다름
- 반이중 : 내가 소켓을 양쪽으로 연결해서 선이 두 개가 만들어짐
클라이언트가 쓰고 서버가 읽고 데이터를 처리하고 응답하고 클라이언트가 다시 읽는 것 // Stateless
반이중은 소켓이 없어지니까 클라이언트의 상태를 기억하지 못함
- 전이중 : 내가 소켓을 양쪽으로 연결해서 선이 두 개가 만들어짐
이 선이 계속 유지되고 있는 것 그래서 원할 때 푸쉬 할 수 있음 // Statefull
5) HTTP(하이퍼텍스트 전송 프로토콜) 요청
- 제너럴(General)
메서드(Method) : 요청의 목적을 나타내는 동사
ex) GET, POST, PUT, DELETE 등
URI(Uniform Resource Identifier) : 요청 대상의 리소스를 식별하는데 사용되는 경로
HTTP 버전 : 사용 중인 HTTP 프로토콜의 버전
- 헤더(Header)
Host : 요청이 전송되는 호스트의 도메인 이름이나 IP 주소
User-Agent : 클라이언트 측에서 사용되는 브라우저 또는 애플리케이션의 정보가 있음
Accept : 클라이언트가 지원하는 컨텐츠 유형 및 데이터 형식
Content-Type : 요청이나 응답의 본문의 유형을 명시 = 바디 타입을 알림
Authorization : 클라이언트가 서버에 대한 인증을 위해 사용하는 정보를 포함
- 바디(Body)
HTTP 요청 바디 : 서버로 전송되는 데이터를 담고 있음
마임타입 : x-www-form-encoded
6) 웹(Stateless)을 Statefull로 만드는 방법
- Statefull : 클라이언트의 상태를 기억할 수 있음
소켓이 이어가고 있으니 클라이언트의 상태를 기억하는 것
⇒ 클라이언트의 상태를 저장하는 것도 전이중
request에 클라이언트의 상태가 저장되어있음
처리 후 reponse 할 때 request, reponse 객체를 버리고 소켓도 잠김
만약 request 객체를 안 남김 → Stateless
선이 끈긴다는 것 : 소켓의 객체를 버린다는 것
ex) 만 명이 요청할 경우 힙공간(객체니까 힙에 뜸)에 만개가 뜨고
안 사라지면 터짐 부화가 큼
→ request정보보다 더 작은 데이터를 저장해야 함
ex) 채팅 - while문을 돌리면서 상대방의 소켓 정보를 렘에 저장하고 있는 것
은행 - 검증을 위해 카드를 두 개를 만듦
사람마다 서랍을 만들어서 따로 보관해서 저장하는 용량을 다 줄임
클라이언트와 서버가 카드를 저장하고 있음
→ request정보를 저장하는 것은 아니지만 카드를 저장하는 것
= 클라이언트의 뭔가를 저장하는 것 : Statefull
이 서랍 : 세션(Session)
애플리케이션에서 사용자 상태를 유지하고 추적하기 위한 메커니즘
서버에서 사용자 상태를 일시적으로 저장하고 관리하는 방법을 제공
세션 저장소(Session Storage) : 서버 측에서 세션 데이터를 저장하는 곳
거기에 저장된 내 카드 : 세션 키(session key)
세션을 식별하는 데 사용되는 고유한 식별자
세션 키가 있다는 것 : 응답이 되도 세션 키는 계속 유지가 됨
올 때마다 서랍은 존재함 날아가지 않음 → Statefull
⇒ Stateless서버를 Statefull처럼 만들기 위해 세션을 사용
ex) 회원가입 시
username과 password를 저장할 때 그 로우를 특정할 수 있는게 프라이머리 키
1번 아이디가 ssar 2번 coss3번 love
자세한 정보는 DB에 저장되어 있음
이 정보를 세션에 저장하면 무겁지만 http 정보보다는 가벼움
만약 내 키에 3을 적으면 3번을 가지고
DB에서 where절에 3을 걸어서 누구인지 알 수 있음
→필요할 때마다 DB에서 꺼내쓸 수 있음 누구인지 특정할 수 있음
Statefull인척 할 수 있으면서 가벼움
부화가 적으면 request에 저장하는 것이 좋음
애초에 전이중으로 만드는 것이 나음
이 모든게 나온 배경 : 컴퓨터의 부화를 줄이기 위해서
반이중으로 해야 부화가 줄기 때문임
상태 저장하면 정보가 너무 크고 무거우니까
→최소한의 정보만 남기고 접근할 수 있는 카드를 가지고 다니는 것
브라우저의 프로토콜로 가능함
(1) 서버한테 요청 → 서버가 상태를 기억하고 싶으면?
ex) 카드를 만들어서 카드를 세션에 첫번째 서랍에 저장 카드 번호 1000번 저장
카드를 줘야 함
(2) 서버는 이 카드를 클라이언트한테 줘야하니까 헤더에 담아줘야 함
데이터가 아니기에 바디에 담기지는 않음
무슨 키값이 담기는지 모름 // 내가 프로토콜을 모르니까
헤더에 Set-Cookie에 담김
서버가 클라이언트에게 쿠키를 설정하도록 지시하는 데 사용되는 헤더
(3) 카드 하나 더 있는 것을 셋 쿠키에 돌려주면
브라우저가 헤더에서 그 카드를 꺼내서 브라우저의 Cookie라는 저장소에 저장
사람이 은행에 가서 카드를 받아서 집에 가져와서 내 주머니에 저장하는 것과 동일
그것을 브라우저가 알아서 함 // 프로토콜을 아니까 가능함
모든 브라우저에 F12를 누르면 애플리케이션에 스토리지에 Cookies가 있음
정보들이 키와 value가 담겨있음
(4) 브라우저가 저장을 하고 다음 요청에 Cookie에 있는 정보를 가지고 가야 함
그래야 서버가 알 수 있음
다시 들고갈 때 request 헤더 키 값에 Cookie에 session key를 담아감
서버가 쿠키를 꺼내서 왔던 사람인지 확인을 위해 비교해보고
왔던 사람이네 확인하는 것까지 프로토콜임
3. 소켓통신 고급
1) process
- 단순히 실행 중인 프로그램(program)
- 프로그램이 운영체제에 의해 메모리 공간을 할당 받아 실행 중인 것
ex) 모든 바이러스도 동작시키려면 메모리를 할당 받아야 함
그래서 pid만 삭제하면 바이러스도 날아감
왜 윈도우에서 못 찾을까?
작업 관리자에 안 나와서 cmd에서 검색해서 찾아야 함 노가다임
2) 스레드
- 프로세스(process) 내에서 실제로 작업을 수행하는 주체를 의미
- 모든 프로세스에는 한 개 이상의 스레드가 존재하여 작업을 수행
- 두 개 이상의 스레드를 가지는 프로세스 : 멀티 스레드 프로세스(multi-threaded process)
- 최근의 트렌드는 스레드를 한 개만 씀 → 나중에 배움..
비동기 프로그램은 단일 스레드로 할 수 있음 / 퍼포먼스가 좋음
4. MIME 타입
1) MIME 타입
- 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘 / 가장 키 포인트
- 웹에서 파일의 확장자는 별 의미가 없음
- 각 문서와 함께 올바른 MIME 타입을 전송하도록, 서버가 정확히 설정하는 것이 중요
- 브라우저들은 리소스를 내려받았을 때 해야 할 기본 동작이 무엇인지를 결정하기 위해 대게 MIME 타입을 사용
- 바이너리 데이터들은 바이트화됨 문자열로 바뀜
이 문자열안에 반드시 뭔지를 알려주는 컨텐트 타입이 있어야함
os단위가 아니라 프로세스 단위에서 알려줘야 파싱할 수 있음
파싱할 때 데이터가 다양하기에 마임 타입을 알아야 파싱할 수 있음
내 마음대로 한글이라고 적을 수 없음
- 형식 : 타이틀/서브 타이틀
큰 개념/작은 개념
- 안적어도 되긴함
html문서에서 안 적으면 랜더링 안됨
- Referrer : 현재 요청한 페이지로 유입된 이전 페이지의 주소를 나타냄
ex) 네이버>날씨
도메인이 다르면 레퍼럴이 없음
→ 비정상적인 접근임을 알 수 있음 / 비정상적인 사용자
헤더에 레퍼럴만 넣으면 해결됨
디바이스 아이디를 확인해서 포스트맨이기에 비정상적급이라고 알 수 있음
그것마저도 보내주면 네이버는 정상적인 접근이라고 알게 됨
2) 중간 언어 이해
- JSON : 현재 전세계 표준 = 경량 데이터
- 그림이 있는 곳에 데이터를 전송할 때 사용함
- 야물이 “”없어서 더 가벼움
설정 파일로 많이 사용됨
5. 서버
1) 서버
웹서버 : http 프로토콜을 사용, html파일을 제공해줌
톰캣은 was : java코드가 필요함
2) 웹 브라우저
- 처음은 논문으로 시작. GET요청만 있었음.
브라우저는 읽는 도구.
- 만드는 건 상관X 앞 뒤로 마크업 HTML TAG만 있으면 됨.
작성/VIEWER만 있음 됨. 한글-V
- 논문 작성하느 ㄴ언어 HTML-V
A태그_하이퍼
- 웹 페이지가 어떻게 구조화.. AIRBNB 박스설계화, CSS
H1을 태그라고도 하고 ELEMETNS라고도 함.
- 평문 P
<마크업> 평문 </>
논문은 HTML로만 만들 수 있음-V
- WJDWJR ZJSXPCM -V
지금은 전송, 수신 함. DB에 INSERT UPDATE DELETE하고 싶을 때 데이터 전송.그 전에는 SELECT GET밖에 없었음.
ZMF>>URI>>웹 서버 (WAS_자바//RS를 JAVA OBJECT로 바꿈.) ><RS(DB_조회RESULT SET)
브라우저에서 URL요청을 해서 DB에서 셀릭트된 데이터가 있음
자바 오브젝트를 json으로 변환해주면 클라이언트는 json데이터만 보니까 의미 없음
그림이 없음
서블릿에서 버퍼에 html코드 집어넣으면서 자바 변수를 집어넣어서 줘야 함
웹은 통신 요청해서 json만 받으면 되니까 restcontroller를 만듦
웹에서는 미리 다운 받아 설치하는게 없음
DB에 요청해서 자바 오브젝트로 바뀐 것을 버퍼에 html 코드 사이에 넣어서 줘야 함
그게 어려워서 템플릿 엔진을 사용함
html로 코딩해서 자바 코드를 섞으면 끝 엄청 편함
그래서 @comtroller가 필요함
머스태취 파일에다 DB에서 조회된 데이터를 섞어서 주는 것
서버 사이드 랜더링 : html의 그림이 서버 쪽에서 html이라는 디자인에 서버섞는 것
랜더링 : 코드에 다 그려서 준다는 것
html에 자바 데이터를 다 집어넣어서 주는것
서버 쪽에서 순수한 html을 완성해서 주기에 받은 쪽에서는 자바 코드가 보이지 않음
랜더링 하면 끝
서버에 요청했을때 html 껍데기만 받고 다시 요청해서 json을 받아서 브라우저에서 그림을 그릴 수 있음
클라이언트 사이드 랜더링 (통신 2번)
: 내부적으로 통신해서 json만 받고 이 데이터를 자바 스크립트 for문 돌리면서 뿌림
클라이언트에 부화가 많이 생김 - 서버 입장에서 유리
캐시 컨트롤러(Cache Controller)도 됨
: 웹 애플리케이션에서 캐싱을 관리하고 제어하는 역할
1번 요청을 해서 스켈레톤 디자인(Skeleton Design)이라고 뼈대만 만들어줌
웹 페이지나 앱에서 사용자가 대기하는 동안 로딩되는 동안 표시되는 간단한 레이어
html,css 1번 : 캐쉬 컨트롤러도 됨 : 정적인 데이터
데이터 2번→ 1번에 2번을 채워넣음
내부적으로 한번 통신을 못 하는것 : 아작스 통신
3) URL(Uniform Resource Locator)
- 사용자가 원하는 정보 위치와 종류를 파악할 수 있도록 웹페이지의 정보 구조를 반영
- 3 요소 : 프로토콜, 아이피, 포트, 자원명
WEB-INF로는 요청 불가
→ 모두 디스패처를 통해야함
강제되어 공통 로직 처리 가능
4) HTTP(Hyper Text Transfer Protocol)
- 송신과 수신의 규약
- get, post, 상태코드 200 404, 쿠키, 컨텐트 타입=마임타입 다 프로토콜
20개 정도는 숙지해야함
6. MVC패턴
1) 모델 1 : 1대 1로 바로 요청할 수 있는 구조
단일 진입점이 없음
2) 모델 2 : FrontController
지휘자를 만드는 것
요청을 보낼 때마다 특정한 작업을 하는 것이 필수적이라면 요청이 들어올 때마다 해당 작업을 실어서 보내야 하는데 이 결과 코드의 중복이 생기고 해당 작업을 누락한다면 최악의 경우에는 장애로 이어질 수도 있음
중복은 코드만 더러워질 뿐 문제가 되지 않지만 누락은 문제가 됨
서블릿 타입이 IF로 라우팅하는것
→ FrontController 패턴 : 요청을 처리하는 지휘자는 해당 작업을 가지고 있고 해당 작업을 처리한 뒤에 요청에 맞는 JSP에게 전달해주는 역할을 함
단점) 다이렉트 호출이 가능 / 강제성이 없음
자바파일에 쓸데없는 자바 코드가 많음
HTML 코드랑 자바 코드가 섞이면 개판됨
퍼블리셔가 JSP파일보면 분석이 안됨
최대한 로직처리를 웬만하면 뷰에서 안하는게 좋음 지저분해짐
비지니스 로직을 컨트롤러에서 처리해서 뷰는 뿌리는 용도로만 쓰는게 좋음
request에 저장된 바디 데이터를 유지하려면 세션에 저장하는 수밖에 없음
세션에는 무거운 데이터를 저장하면 좋지 않음
3) 모델 3 : MVC 패턴
컨트롤러를 분리시킴
ex) 회원가입을 하는데 로그인이 되어있으면 안됨
회원정보 페이지나 게시글을 작성할 때는 로그인이 되어있어야 함
외부에서 들어오면 WEB.XML로 중국 IP 다 팅겨냄
인증된 애만 들어올 수 있게 필터링 안 할 수도 있음
나머지는 들어와서 인증이 안되어있어도 로그인이나 회원가입이 가능
게시글 쓰기, 삭제만 가능한 컨트롤러에는 로그인이 안되어있으면 접근 물가
내부에서도 필터링이 가능함
ex) 아파트 자체는 아파트 주민만 들어올 수 있지만 우리 집은 나만 들어갈 수 있음
인증이 안되도 아파트에는 들어올 수 있음
ex) 게시글 삭제라는 것은 로그인이 되어있어야 하고 /인증
내가 1번이여야 함/권한
→ 인증과 권한이 필요한 로직이 있음
인증이 안되도 들어갈 수 있는 페이지와 인증이 되야 들어갈 수 잇는 페이지
그리고 내 메일을 보려면 권한도 있어야 함
인증과 권한, 인증이 없는 것 : 3가지를 세션으로 구분해서 사용함
Share article
