15장
운영체제
컴퓨터는 3가지 레이어(층)으로 나뉜다.
input/output은 Application 입장에서 위의 그림은 skip해도 됨. 정확하게는 아래 참조
프로그램을 실행하면 프로세스.
so, byte 흘러가는 stream = 8bit가 흘러가는 stream
Application 영역 stream : byte stream
stream
= 끝이 없는 byte 흐름
stream에 데이터가 들어오면 이런 식으로 쌓임
but 이렇게 다 차면 이런 식으로 늘어남
⇒ 끝이 없는(무한대의) byte 저장공간
ex) 흘러가는 송유관(끝이 없는)
data 공급될 때 예를 들어 1초에 1개씩 가능하고 그게 딱 맞으면 okay.
but 컴퓨터는 이렇게 되지 않음. 다양한 원인(프로그램, 스레드 등)때문에
data 연속적으로 흘러갈 때 여러 이유로 6s 걸릴 수 있음
⇒ 쌓이면 버려짐-v
⇒so 버퍼가 필요함
버퍼는 소비가 공급보다 빠를 때 혹은 느릴 때 딱 안 맞을 때 생김
공급이 소비보다 빠를 때, 느릴 때 딱 안 맞을 때 버퍼가 생김
채팅인 경우 보조스트림 정할 수 없음.
->if 끝을 정했다면, 예를 들어 50byte로 정했다면
50byte이상은 못적어.그리고 문자를 적게 적을 때면 낭비가 생김
=> So, 보조스트림은 아래와 같이 만듦보조스트림
ㅤ | ㅤ | ㅤ | ㅤ |
버퍼가 되면 특이하게 작동함.-v
통신 시 배열처럼 3,4는 안됨.
예를 들어 버퍼는 Hello(5글자)가 들어오면 O는 보조 Stream 다 차서 Stream물 길에 갇혀있다.
다 찼으니 H 소비
⇒ H OS소비 ⇒E 소비
H 소비하자마자 버퍼에 O가 찬다.
⇒ 계속 이런식으로 Ing ⇒…
⇒보조스트림이 아래와 같이 비게 됨.
이런 식으로 파일을 쓰면 (다 차면) 한 개씩 소비하고 다음 거 채워지는 식으로 하면 문자 길어도 받을 수 있다-v
개발자는 data를 보조스트림에 던지면 끝 정도 기억
(앱 2개 그림)
App1,2 동시에 처리해야 함⇒ 스레드 2개 필요
(ex) 프로세스 10개면 스레드 10개 필요)
버퍼가 꽉 차야 내려옴 ⇒ 안 차면 안 흘러감
⇒ 그렇다면, 전부 다 안 찼을 때 흘리고 싶다 ⇒ 강제로 흘려보냄 : Flush
(보조스트림 다 차면 flush 안 해도 알아서 내려옴)
ex) 예를 들어 bye 같은 것은 버터(4칸이라 하면)가 다 안 차임. 다 안 차이면 소비x⇒ os가 data를 안 가져감
쓰기버퍼
app입장에서 data를 쓰는 것이니까 보조스트림은 쓰기버터이다.(output stream)
패킷스트림
os입장에서 읽기 버퍼(input)
보조스트림 성격
-read
-write
소캣이 뭐야..
byte stream
한 바이트씩 받아서 a만 받음
ab가 와도
os가 a만 소비함.(b는 버려짐)
⇒ 해결하기 위해 ⇒보조 스트림
우리는 data를 보조
os가 data 받을 때 app 1,2 동시 사용할 때
⇒ 서로 데이터가 섞이면 안되니까 스레드 필요
→ 이 경우 app 1,2니까 스레드 2개 필요
(app 1,2는프로세스_ 실행하고 있으니께)
ex) if 프로세스 10개면 스레드 10개 필요
flush
데이터가 다 안 찼지만 강제로 내려보내야 할 때
-flush하면 모든 물길이 열림
ex) 데이터 크기 4인데 bye하면 한 칸 남음. 그렇지만 done⇒ flush함
-데이터가 꽉 차는 경우, 알아서 내려옴.(ex> lion flush 안 해도 알아서 내려옴. )
System.out : 모니터
ex) System.out.print
System.in : 키보드
보조스트림
-app 입장에서, app 층 스트림은 byte stream!. os는 다른 stream이다.
-app 입장에서는 첫번째 스트림은 쓰기버퍼.(output stream)
-키보드에서 받을 때는 읽기버터가 됨?-v
성격
-read
-write
통신의 기본 5가지
TCP
스위칭
패킷(바디, 헤더)
IP
LAN
통신-v : tcp/udp
TCP
조건) 3번 왔다 갔다
⇒ 신뢰성 있는 통신
UDP
신뢰성 없는 통신,
(A →B에게 주기만 함.)
동영상에 적합-v
EX) A,B가 인터넷 전화할 때
A “야 너 진짜 못생”
→ 통신에서 유실됨.(신뢰성 없는 통신이라)
B 알아들음(인간이니까)
EX) 동영상
STREAM끝이 없는 개울.
동영상 STREAMING : 연속해서 보내-V
사진 5장,1~2장 보내도(잃어도) 알아듣고 속도가 중요.
신뢰성 있는 통신-느리다
pw같은 것들은 tcp해야 함.
신뢰성 없는 통신-빠르다 ⇒ 인간에게만 가능. 컴퓨터에 보내기에는 부적절
너는 생겼다. 이거는 뜻 잘 모름(잘?못?) 인간이 봐도 신뢰성 있게 보내야 하는 것도 있음
전화, striming -v아니면 tcp를 씀
3hands
a → b
전용선
서킷스위칭
통신할 때는 서킷스위칭 쓰지x
통신할 때 패킷, 세그먼트로 해야 — 전송가능-v
통신의 파일 : 소켓
소켓이 세그먼트로 쪼갬-v
data > 소켓 > 세그먼트
파일이 어쩔 때는 소캣이고 어쩔 때는 파일-v
패킷스위칭 씀(돈도 아끼고 지연시간도 없애고)
패킷포워드 장치 : 라우터-v
라우터에서 데이터 유실 : 자기 용량 초과 혹은 많이 몰려 에러가 생길 수 있음
→ so tcp를 씀
→ack 응답을 함. → 다시 한 번 응답
→ack응답x→ 재전송(한 3번 정도)→통신 중단, 에러 됨.
8192byte? / 3? 버퍼니까 전송된다고??
동영상 1mb면 패킷으로 쪼개고 쪼갠만큼 헤더가 생김
그래서 헤더데이트때문에 늘어남. 보통 패킷은 1500byte
헤더 : 1400byte?
메모장에서 흘러가는 데이터가.. 팻킷이 만들어진다? 1mb / 7???
abc로 나뉘지 않음.예를 든것. 더 크게 쪼개짐.
다 헤더 붙음(목적지, 출발지 ip)_팻킷-바디에??
ip
전세계 컴터가 있는데
host 인터넷 되는 모든 장치 ex)컴퓨터, tv, 워치
패킷 스위칭이니까 한번에 못 보내고 잘게 쪼갬→ 어떤 용량을 쓰면 write버퍼에 가서 파일로 가서 통신.소켓.
메일프로그램(write버퍼) →메일프로그램(read버퍼)
os가 가진 소캣(⇒파일)
- 파일이 세그먼트로 바뀜’? 스트림 크기 : 보내는 사람이 정함 1mbte를 보내면 segment로 쪼개져서 대충 7개로 쪼개지면
1(헤더) | 2 | 3 | 4 | 5 | 6 | 7 |
1460 byte(바디 body=페이로드payload) | ㅤ | ㅤ | ㅤ | ㅤ | ㅤ | ㅤ |
2.위의 아이를 패킷으로 만듦
출발지 : ip
도착지 : ip
ll
>hw
패킷
패킷의 주소를 보고 가장 가까운 라우터로 감.-v
목적지 : 가장 가까운 라우터
세그먼트라는 것은 ….택배박스는 헤더는 안 까도 위에 있음(송장)
가장 가까운 곳으로 간다고? 트럭을 갈아탄다고? 컴 > 1> 2
5번이라면 가장 최적의 경로를 찾아(라우터) 그래서 프레임 벗겨 목적지 주소만 보고 트럭만 보고? 다음 라우터 ?(말을 갈아타는 곳=역창??????)-v 새 말 =새 주소⇒ 동적??? 무슨 말이야?,,,,,
hw > 패킷ack > 세그먼트 재조립
그렇게 7번까지 받는다고?? 그럼 데이터 완성? 그래서 메인프로그램에 받아서 출력을 한다고?
패킷은 ip주소 헤더
세그 데이터 주소?
프레임-전송 type?
ip -host의 유일한 값(primary 키 같은)
프로그램
소켓
os
소켓 = os가 가지고 있는 파일인데 통신할 때 소켓이라고 한다.
프레임 : 트럭 차, 라우터로 이동할 때 쓰는 이동 수단(목적지는 가장 가까운 라우터)
목적지는 계속 변경된다.(같은 경로가 있으면 덜 바쁜 쪽으로 가기 때문에. 동적이다.)
-
앱에서 스트림>쓰기버퍼>스트림>소캣> os > Hw
파일은 소캣이다라는 말은… 파일 = 소캣이란 말이 아니라
소캣이 컴퓨터에서 구조가 파일처럼 쓰인다..란 말이다.
app 영역은 : 지금 실행하고 있는 프로그램(프로세스) 느낌
3way handshake
안녕 > 안녕이라고 했지? >okay
스위칭
패킷(바디, 헤더)
Share article